Merge remote-tracking branch 'upstream/main' into dev-1.24
This commit is contained in:
Nate W
+13
-13
@@ -3,13 +3,13 @@
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](https://github.com/kubernetes/website/releases/latest)
|
||||
|
||||
Herzlich willkommen! Dieses Repository enthält alle Assets, die zur Erstellung der [Kubernetes-Website und Dokumentation](https://kubernetes.io/) erforderlich sind. Wir freuen uns sehr, dass Sie dazu beitragen wollen!
|
||||
Herzlich Willkommen! Dieses Repository enthält alle Assets, die zur Erstellung der [Kubernetes-Website und Dokumentation](https://kubernetes.io/) erforderlich sind. Wir freuen uns sehr, dass Sie dazu beitragen wollen!
|
||||
|
||||
## Beiträge zur Dokumentation
|
||||
|
||||
Sie können auf die Schaltfläche **Fork** im oberen rechten Bereich des Bildschirms klicken, um eine Kopie dieses Repositorys in Ihrem GitHub-Konto zu erstellen. Diese Kopie wird als *Fork* bezeichnet. Nehmen Sie die gewünschten Änderungen an Ihrem Fork vor. Wenn Sie bereit sind, diese Änderungen an uns zu senden, gehen Sie zu Ihrem Fork und erstellen Sie eine neue Pull-Anforderung, um uns darüber zu informieren.
|
||||
Sie können auf die Schaltfläche **Fork** im oberen rechten Bereich des Bildschirms klicken, um eine Kopie dieses Repositorys in Ihrem GitHub-Konto zu erstellen. Diese Kopie wird als *Fork* bezeichnet. Nehmen Sie die gewünschten Änderungen an Ihrem Fork vor. Wenn Sie bereit sind, diese Änderungen an uns zu senden, gehen Sie zu Ihrem Fork und erstellen Sie eine neue Pull-Request, um uns darüber zu informieren.
|
||||
|
||||
Sobald Ihre Pull-Anfrage erstellt wurde, übernimmt ein Rezensent von Kubernetes die Verantwortung für klares, umsetzbares Feedback. Als Eigentümer des Pull-Request **liegt es in Ihrer Verantwortung Ihren Pull-Reqest entsprechend des Feedbacks, dass Sie vom Kubernetes-Reviewer erhalten haben abzuändern.** Beachten Sie auch, dass Sie am Ende mehr als einen Rezensenten von Kubernetes erhalten, der Ihnen Feedback gibt, oder dass Sie Rückmeldungen von einem Rezensenten von Kubernetes erhalten, der sich von demjenigen unterscheidet, der ursprünglich für das Feedback zugewiesen wurde. In einigen Fällen kann es vorkommen, dass einer Ihrer Prüfer bei Bedarf eine technische Überprüfung von einem [Kubernetes Tech-Reviewer](https://github.com/kubernetes/website/wiki/tech-reviewers) anfordert. Reviewer geben ihr Bestes, um zeitnah Feedback zu geben, die Antwortzeiten können jedoch je nach den Umständen variieren.
|
||||
Sobald Ihre Pull-Request erstellt wurde, übernimmt ein Rezensent von Kubernetes die Verantwortung für klares, umsetzbares Feedback. Als Eigentümer des Pull-Request **liegt es in Ihrer Verantwortung Ihre Pull-Request entsprechend des Feedbacks, welches Sie vom Kubernetes-Reviewer erhalten haben, abzuändern.** Beachten Sie auch, dass Sie am Ende mehr als einen Rezensenten von Kubernetes erhalten, der Ihnen Feedback gibt, oder dass Sie Rückmeldungen von einem Rezensenten von Kubernetes erhalten, der sich von demjenigen unterscheidet, der ursprünglich für das Feedback zugewiesen wurde. In einigen Fällen kann es vorkommen, dass einer Ihrer Prüfer bei Bedarf eine technische Überprüfung von einem [Kubernetes Tech-Reviewer](https://github.com/kubernetes/website/wiki/tech-reviewers) anfordert. Reviewer geben ihr Bestes, um zeitnah Feedback zu geben, die Antwortzeiten können jedoch je nach den Umständen variieren.
|
||||
|
||||
Weitere Informationen zum Beitrag zur Kubernetes-Dokumentation finden Sie unter:
|
||||
|
||||
@@ -28,14 +28,14 @@ Die Betreuer der deutschen Lokalisierung erreichen Sie unter:
|
||||
* Max Körbächer ([@mkorbi](https://github.com/mkorbi))
|
||||
* [Slack Kanal](https://kubernetes.slack.com/messages/kubernetes-docs-de)
|
||||
|
||||
## Site lokal mit Docker ausführen
|
||||
## Website lokal mit Docker ausführen
|
||||
|
||||
Um die Kubernetes-Website lokal laufen zu lassen, empfiehlt es sich, ein spezielles [Docker](https://docker.com) Image auszuführen, das den statischen Site-Generator [Hugo](https://gohugo.io) enthält.
|
||||
Um die Kubernetes-Website lokal laufen zu lassen, empfiehlt es sich, ein spezielles [Docker](https://docker.com) Image auszuführen, das den statischen Website-Generator [Hugo](https://gohugo.io) enthält.
|
||||
|
||||
> Unter Windows benötigen Sie einige weitere Tools, die Sie mit [Chocolatey](https://chocolatey.org) installieren können.
|
||||
`choco install make`
|
||||
|
||||
> Wenn Sie die Website lieber lokal ohne Docker ausführen möchten, finden Sie weitere Informationen unter [Website lokal mit Hugo ausführen](#Die-Site-lokal-mit-Hugo-ausführen).
|
||||
> Wenn Sie die Website lieber lokal ohne Docker ausführen möchten, finden Sie weitere Informationen unter [Website lokal mit Hugo ausführen](#Die-Website-lokal-mit-Hugo-ausführen).
|
||||
|
||||
Das benötigte [Docsy Hugo theme](https://github.com/google/docsy#readme) muss als git submodule installiert werden:
|
||||
|
||||
@@ -50,26 +50,26 @@ Wenn Sie Docker [installiert](https://www.docker.com/get-started) haben, erstell
|
||||
make container-image
|
||||
```
|
||||
|
||||
Nachdem das Image erstellt wurde, können Sie die Site lokal ausführen:
|
||||
Nachdem das Image erstellt wurde, können Sie die Website lokal öffnen:
|
||||
|
||||
```bash
|
||||
make container-serve
|
||||
```
|
||||
|
||||
Öffnen Sie Ihren Browser unter http://localhost:1313, um die Site anzuzeigen. Wenn Sie Änderungen an den Quelldateien vornehmen, aktualisiert Hugo die Site und erzwingt eine Browseraktualisierung.
|
||||
Öffnen Sie Ihren Browser unter http://localhost:1313, um die Website anzuzeigen. Wenn Sie Änderungen an den Quelldateien vornehmen, aktualisiert Hugo die Website und erzwingt eine Browseraktualisierung.
|
||||
|
||||
## Die Site lokal mit Hugo ausführen
|
||||
## Die Website lokal mit Hugo ausführen
|
||||
|
||||
Hugo-Installationsanweisungen finden Sie in der [offiziellen Hugo-Dokumentation](https://gohugo.io/getting-started/installing/). Stellen Sie sicher, dass Sie die Hugo-Version installieren, die in der Umgebungsvariablen `HUGO_VERSION` in der Datei [`netlify.toml`](netlify.toml#L9) angegeben ist.
|
||||
|
||||
Das benötigte [Docsy Hugo theme](https://github.com/google/docsy#readme) muss als git submodule installiert werden:
|
||||
Das benötigte [Docsy Hugo-Theme](https://github.com/google/docsy#readme) muss als git submodule installiert werden:
|
||||
|
||||
```
|
||||
#Füge das Docsy submodule hinzu
|
||||
git submodule update --init --recursive --depth 1
|
||||
```
|
||||
|
||||
So führen Sie die Site lokal aus, wenn Sie Hugo installiert haben:
|
||||
So führen Sie die Website lokal aus, wenn Sie Hugo installiert haben:
|
||||
|
||||
```bash
|
||||
# Installieren der JavaScript Abhängigkeiten
|
||||
@@ -77,7 +77,7 @@ npm ci
|
||||
make serve
|
||||
```
|
||||
|
||||
Dadurch wird der lokale Hugo-Server an Port 1313 gestartet. Öffnen Sie Ihren Browser unter http://localhost:1313, um die Site anzuzeigen. Wenn Sie Änderungen an den Quelldateien vornehmen, aktualisiert Hugo die Site und erzwingt eine Browseraktualisierung.
|
||||
Dadurch wird der lokale Hugo-Server an Port 1313 gestartet. Öffnen Sie Ihren Browser unter http://localhost:1313, um die Website anzuzeigen. Wenn Sie Änderungen an den Quelldateien vornehmen, aktualisiert Hugo die Website und erzwingt eine Browseraktualisierung.
|
||||
|
||||
## Community, Diskussion, Beteiligung und Unterstützung
|
||||
|
||||
@@ -94,4 +94,4 @@ Die Teilnahme an der Kubernetes-Community unterliegt dem [Kubernetes-Verhaltensk
|
||||
|
||||
## Vielen Dank!
|
||||
|
||||
Kubernetes lebt vom Community Engagement und wir freuen uns sehr über Ihre Beiträge zu unserer Website und unserer Dokumentation!
|
||||
Kubernetes lebt vom Community-Engagement und wir freuen uns sehr über Ihre Beiträge zu unserer Website und unserer Dokumentation!
|
||||
|
||||
@@ -329,6 +329,11 @@ main {
|
||||
.td-content>table td {
|
||||
word-break: break-word;
|
||||
}
|
||||
|
||||
table.no-word-break td,
|
||||
table.no-word-break code {
|
||||
word-break: normal;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -396,8 +401,8 @@ body {
|
||||
}
|
||||
|
||||
.deprecation-warning, .pageinfo.deprecation-warning {
|
||||
padding: 20px;
|
||||
margin: 20px 0;
|
||||
padding: clamp(10px, 2vmin, 20px);
|
||||
margin: clamp(10px, 1vh, 20px) 0;
|
||||
background-color: #faf5b6;
|
||||
color: #000;
|
||||
}
|
||||
@@ -411,6 +416,9 @@ body.td-home .deprecation-warning, body.td-blog .deprecation-warning, body.td-do
|
||||
border-radius: 3px;
|
||||
}
|
||||
|
||||
.deprecation-warning p:only-child {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
.td-documentation .td-content > .highlight {
|
||||
max-width: initial;
|
||||
|
||||
@@ -3,6 +3,7 @@ layout: blog
|
||||
title: "Kubernetes 1.17: Stability"
|
||||
date: 2019-12-09T13:00:00-08:00
|
||||
slug: kubernetes-1-17-release-announcement
|
||||
evergreen: true
|
||||
---
|
||||
|
||||
**Authors:** [Kubernetes 1.17 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.17/release_team.md)
|
||||
|
||||
@@ -3,6 +3,7 @@ layout: blog
|
||||
title: 'Kubernetes 1.18: Fit & Finish'
|
||||
date: 2020-03-25
|
||||
slug: kubernetes-1-18-release-announcement
|
||||
evergreen: true
|
||||
---
|
||||
|
||||
**Authors:** [Kubernetes 1.18 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md)
|
||||
|
||||
@@ -3,6 +3,7 @@ layout: blog
|
||||
title: 'Kubernetes 1.19: Accentuate the Paw-sitive'
|
||||
date: 2020-08-26
|
||||
slug: kubernetes-release-1.19-accentuate-the-paw-sitive
|
||||
evergreen: true
|
||||
---
|
||||
|
||||
**Authors:** [Kubernetes 1.19 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.19/release_team.md)
|
||||
|
||||
@@ -3,9 +3,10 @@ layout: blog
|
||||
title: "Warning: Helpful Warnings Ahead"
|
||||
date: 2020-09-03
|
||||
slug: warnings
|
||||
evergreen: true
|
||||
---
|
||||
|
||||
**Author**: Jordan Liggitt (Google)
|
||||
**Author**: [Jordan Liggitt](https://github.com/liggitt) (Google)
|
||||
|
||||
As Kubernetes maintainers, we're always looking for ways to improve usability while preserving compatibility.
|
||||
As we develop features, triage bugs, and answer support questions, we accumulate information that would be helpful for Kubernetes users to know.
|
||||
@@ -327,7 +328,3 @@ A couple areas we're looking at next are warning about [known problematic values
|
||||
we cannot reject outright for compatibility reasons, and warning about use of deprecated fields or field values
|
||||
(like selectors using beta os/arch node labels, [deprecated in v1.14](/docs/reference/labels-annotations-taints/#beta-kubernetes-io-arch-deprecated)).
|
||||
I'm excited to see progress in this area, continuing to make it easier to use Kubernetes.
|
||||
|
||||
---
|
||||
|
||||
_[Jordan Liggitt](https://twitter.com/liggitt) is a software engineer at Google, and helps lead Kubernetes authentication, authorization, and API efforts._
|
||||
@@ -3,6 +3,7 @@ layout: blog
|
||||
title: 'Kubernetes 1.20: The Raddest Release'
|
||||
date: 2020-12-08
|
||||
slug: kubernetes-1-20-release-announcement
|
||||
evergreen: true
|
||||
---
|
||||
|
||||
**Authors:** [Kubernetes 1.20 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.20/release_team.md)
|
||||
|
||||
@@ -3,6 +3,7 @@ layout: blog
|
||||
title: 'Kubernetes 1.21: Power to the Community'
|
||||
date: 2021-04-08
|
||||
slug: kubernetes-1-21-release-announcement
|
||||
evergreen: true
|
||||
---
|
||||
|
||||
**Authors:** [Kubernetes 1.21 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.21/release-team.md)
|
||||
|
||||
@@ -3,6 +3,7 @@ layout: blog
|
||||
title: 'Kubernetes 1.22: Reaching New Peaks'
|
||||
date: 2021-08-04
|
||||
slug: kubernetes-1-22-release-announcement
|
||||
evergreen: true
|
||||
---
|
||||
|
||||
**Authors:** [Kubernetes 1.22 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.22/release-team.md)
|
||||
|
||||
@@ -96,15 +96,16 @@ out.
|
||||
First install the volume-data-source-validator controller.
|
||||
|
||||
```terminal
|
||||
kubectl apply -f https://github.com/kubernetes-csi/volume-data-source-validator/blob/master/deploy/kubernetes/rbac-data-source-validator.yaml
|
||||
kubectl apply -f https://github.com/kubernetes-csi/volume-data-source-validator/blob/master/deploy/kubernetes/setup-data-source-validator.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/volume-data-source-validator/master/client/config/crd/populator.storage.k8s.io_volumepopulators.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/volume-data-source-validator/master/deploy/kubernetes/rbac-data-source-validator.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/volume-data-source-validator/master/deploy/kubernetes/setup-data-source-validator.yaml
|
||||
```
|
||||
|
||||
Next install the example populator.
|
||||
|
||||
```terminal
|
||||
kubectl apply -f https://github.com/kubernetes-csi/lib-volume-populator/blob/master/example/hello-populator/crd.yaml
|
||||
kubectl apply -f https://github.com/kubernetes-csi/lib-volume-populator/blob/master/example/hello-populator/deploy.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/lib-volume-populator/master/example/hello-populator/crd.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/lib-volume-populator/master/example/hello-populator/deploy.yaml
|
||||
```
|
||||
|
||||
Create an instance of the `Hello` CR, with some text.
|
||||
|
||||
@@ -3,6 +3,7 @@ layout: blog
|
||||
title: 'Kubernetes 1.23: The Next Frontier'
|
||||
date: 2021-12-07
|
||||
slug: kubernetes-1-23-release-announcement
|
||||
evergreen: true
|
||||
---
|
||||
|
||||
**Authors:** [Kubernetes 1.23 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.23/release-team.md)
|
||||
|
||||
@@ -93,7 +93,7 @@ For self-registration, the kubelet is started with the following options:
|
||||
No-op if `register-node` is false.
|
||||
- `--node-ip` - IP address of the node.
|
||||
- `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)).
|
||||
- `--node-status-update-frequency` - Specifies how often kubelet posts node status to master.
|
||||
- `--node-status-update-frequency` - Specifies how often kubelet posts its node status to the API server.
|
||||
|
||||
When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
|
||||
@@ -335,7 +335,7 @@ the same time:
|
||||
(default 0.01) per second.
|
||||
|
||||
The reason these policies are implemented per availability zone is because one
|
||||
availability zone might become partitioned from the master while the others remain
|
||||
availability zone might become partitioned from the control plane while the others remain
|
||||
connected. If your cluster does not span multiple cloud provider availability zones,
|
||||
then the eviction mechanism does not take per-zone unavailability into account.
|
||||
|
||||
|
||||
@@ -57,7 +57,15 @@ The output is:
|
||||
...
|
||||
```
|
||||
|
||||
You can use `kubectl logs --previous` to retrieve logs from a previous instantiation of a container. If your pod has multiple containers, specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
|
||||
You can use `kubectl logs --previous` to retrieve logs from a previous instantiation of a container.
|
||||
If your pod has multiple containers, specify which container's logs you want to access by
|
||||
appending a container name to the command, with a `-c` flag, like so:
|
||||
|
||||
```console
|
||||
kubectl logs counter -c count
|
||||
```
|
||||
|
||||
See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
|
||||
|
||||
## Logging at the node level
|
||||
|
||||
|
||||
@@ -146,14 +146,6 @@ data:
|
||||
extra: YmFyCg==
|
||||
```
|
||||
|
||||
When creating a `Pod`, Kubernetes automatically creates a service account Secret
|
||||
and automatically modifies your Pod to use this Secret. The service account token
|
||||
Secret contains credentials for accessing the API.
|
||||
|
||||
The automatic creation and use of API credentials can be disabled or
|
||||
overridden if desired. However, if all you need to do is securely access the
|
||||
API server, this is the recommended workflow.
|
||||
|
||||
See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
documentation for more information on how service accounts work.
|
||||
You can also check the `automountServiceAccountToken` field and the
|
||||
@@ -161,6 +153,20 @@ You can also check the `automountServiceAccountToken` field and the
|
||||
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
|
||||
for information on referencing service account from Pods.
|
||||
|
||||
{{< note >}}
|
||||
Automatic creation of API credentials in secrets to mount into running pods
|
||||
is no longer used in v1.22 and newer versions. Instead, API credentials are
|
||||
obtained directly by using the [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API,
|
||||
and are mounted into Pods using a [projected volume](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume).
|
||||
The tokens obtained using this method have bounded lifetimes, and are automatically
|
||||
invalidated when the Pod they are mounted into is deleted.
|
||||
|
||||
Service account token secrets can still be [created manually](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
|
||||
if you need a token that never expires.
|
||||
However, using the [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
|
||||
subresource to obtain a token to access the API is recommended instead.
|
||||
{{< /note >}}
|
||||
|
||||
### Docker config Secrets
|
||||
|
||||
You can use one of the following `type` values to create a Secret to
|
||||
|
||||
@@ -39,6 +39,7 @@ Customization approaches can be broadly divided into *configuration*, which only
|
||||
*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary:
|
||||
|
||||
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
|
||||
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
|
||||
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
|
||||
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
|
||||
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
|
||||
|
||||
@@ -230,7 +230,6 @@ The following example describes how to map secret values into application enviro
|
||||
* If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/).
|
||||
* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
|
||||
* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
|
||||
* View [svc-cat.io](https://svc-cat.io/docs/).
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Control plane components can be run on any machine in the cluster. However,
|
||||
for simplicity, set up scripts typically start all control plane components on
|
||||
the same machine, and do not run user containers on this machine. See
|
||||
[Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
|
||||
for an example control plane setup that runs across multiple VMs.
|
||||
for an example control plane setup that runs across multiple machines.
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
|
||||
@@ -11,9 +11,13 @@ weight: 30
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
|
||||
|
||||
PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. It has been replaced by
|
||||
[Pod Security Admission](/docs/concepts/security/pod-security-admission/). For more information on the deprecation,
|
||||
{{< caution >}}
|
||||
PodSecurityPolicy is deprecated as of Kubernetes v1.21, and **will be removed in v1.25**. We recommend migrating to
|
||||
[Pod Security Admission](/docs/concepts/security/pod-security-admission/), or a 3rd party admission plugin.
|
||||
For a migration guide, see [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp/).
|
||||
For more information on the deprecation,
|
||||
see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/).
|
||||
{{< /caution >}}
|
||||
|
||||
Pod Security Policies enable fine-grained authorization of pod creation and
|
||||
updates.
|
||||
|
||||
@@ -123,7 +123,7 @@ Area of Concern for Containers | Recommendation |
|
||||
Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities.
|
||||
Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers.
|
||||
Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container.
|
||||
Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provider stronger isolation
|
||||
Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provide stronger isolation
|
||||
|
||||
## Code
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ The Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-sta
|
||||
different isolation levels for Pods. These standards let you define how you want to restrict the
|
||||
behavior of pods in a clear, consistent fashion.
|
||||
|
||||
As an Beta feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip
|
||||
As a Beta feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip
|
||||
text="admission controller" term_id="admission-controller" >}}, the successor
|
||||
to [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/). Pod security restrictions
|
||||
are applied at the {{< glossary_tooltip text="namespace" term_id="namespace" >}} level when pods
|
||||
@@ -125,7 +125,7 @@ applied to workload resources, only to the resulting pod objects.
|
||||
|
||||
## Exemptions
|
||||
|
||||
You can define _exemptions_ from pod security enforcement in order allow the creation of pods that
|
||||
You can define _exemptions_ from pod security enforcement in order to allow the creation of pods that
|
||||
would have otherwise been prohibited due to the policy associated with a given namespace.
|
||||
Exemptions can be statically configured in the
|
||||
[Admission Controller configuration](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller).
|
||||
|
||||
@@ -52,8 +52,8 @@ fail validation.
|
||||
<caption style="display:none">Baseline policy specification</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>Control</strong></td>
|
||||
<td><strong>Policy</strong></td>
|
||||
<th>Control</th>
|
||||
<th>Policy</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="white-space: nowrap">HostProcess</td>
|
||||
|
||||
@@ -147,9 +147,9 @@ In the v1 API, the per endpoint `topology` was effectively removed in favor of
|
||||
the dedicated fields `nodeName` and `zone`.
|
||||
|
||||
Setting arbitrary topology fields on the `endpoint` field of an `EndpointSlice`
|
||||
resource has been deprecated and is not be supported in the v1 API. Instead,
|
||||
the v1 API supports setting individual `nodeName` and `zone` fields. These
|
||||
fields are automatically translated between API versions. For example, the
|
||||
resource has been deprecated and is not supported in the v1 API.
|
||||
Instead, the v1 API supports setting individual `nodeName` and `zone` fields.
|
||||
These fields are automatically translated between API versions. For example, the
|
||||
value of the `"topology.kubernetes.io/zone"` key in the `topology` field in
|
||||
the v1beta1 API is accessible as the `zone` field in the v1 API.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -83,6 +83,15 @@ To submit a blog post follow these directions:
|
||||
- _initial commit_
|
||||
- _draft post_
|
||||
- The blog team will then review your PR and give you comments on things you might need to fix. After that the bot will merge your PR and your blog post will be published.
|
||||
- If the content of the blog post contains only content that is not expected to require updates to stay accurate for the reader, it can be marked as evergreen and exempted from the automatic warning about outdated content added to blog posts older than one year.
|
||||
- To mark a blog post as evergreen, add this to the front matter:
|
||||
|
||||
```yaml
|
||||
evergreen: true
|
||||
```
|
||||
- Examples of content that should not be marked evergreen:
|
||||
- **Tutorials** that only apply to specific releases or versions and not all future versions
|
||||
- References to pre-GA APIs or features
|
||||
|
||||
|
||||
## Submit a case study
|
||||
|
||||
@@ -66,6 +66,7 @@ client libraries:
|
||||
|
||||
* List of [ports and protocols](/docs/reference/ports-and-protocols/) that
|
||||
should be open on control plane and worker nodes
|
||||
|
||||
## Config APIs
|
||||
|
||||
This section hosts the documentation for "unpublished" APIs which are used to
|
||||
@@ -73,12 +74,12 @@ configure kubernetes components or tools. Most of these APIs are not exposed
|
||||
by the API server in a RESTful way though they are essential for a user or an
|
||||
operator to use or manage a cluster.
|
||||
|
||||
|
||||
* [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
|
||||
* [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/)
|
||||
* [kubelet credential providers (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/)
|
||||
* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) and
|
||||
[kube-scheduler configuration (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
* [kube-proxy configuration (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
|
||||
|
||||
@@ -1144,7 +1144,9 @@ If specified, `clientKeyData` and `clientCertificateData` must both must be pres
|
||||
{{< /tabs >}}
|
||||
|
||||
Optionally, the response can include the expiry of the credential formatted as a
|
||||
RFC3339 timestamp. Presence or absence of an expiry has the following impact:
|
||||
[RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339) timestamp.
|
||||
|
||||
Presence or absence of an expiry has the following impact:
|
||||
|
||||
- If an expiry is included, the bearer token and TLS credentials are cached until
|
||||
the expiry time is reached, or if the server responds with a 401 HTTP status code,
|
||||
|
||||
@@ -34,8 +34,8 @@ Write operations:
|
||||
|
||||
Auth-related operations:
|
||||
|
||||
* read/write access to the certificationsigningrequests API for TLS bootstrapping
|
||||
* the ability to create tokenreviews and subjectaccessreviews for delegated authentication/authorization checks
|
||||
* read/write access to the [CertificateSigningRequests API](/docs/reference/access-authn-authz/certificate-signing-requests/) for TLS bootstrapping
|
||||
* the ability to create TokenReviews and SubjectAccessReviews for delegated authentication/authorization checks
|
||||
|
||||
In future releases, the node authorizer may add or remove permissions to ensure kubelets
|
||||
have the minimal set of permissions required to operate correctly.
|
||||
|
||||
@@ -0,0 +1,275 @@
|
||||
---
|
||||
reviewers:
|
||||
- tallclair
|
||||
- liggitt
|
||||
title: Mapping PodSecurityPolicies to Pod Security Standards
|
||||
content_type: concept
|
||||
weight: 95
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
The tables below enumerate the configuration parameters on
|
||||
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) objects, whether the field mutates
|
||||
and/or validates pods, and how the configuration values map to the
|
||||
[Pod Security Standards](/docs/concepts/security/pod-security-standards/).
|
||||
|
||||
For each applicable parameter, the allowed values for the
|
||||
[Baseline](/docs/concepts/security/pod-security-standards/#baseline) and
|
||||
[Restricted](/docs/concepts/security/pod-security-standards/#restricted) profiles are listed.
|
||||
Anything outside the allowed values for those profiles would fall under the
|
||||
[Privileged](/docs/concepts/security/pod-security-standards/#priveleged) profile. "No opinion"
|
||||
means all values are allowed under all Pod Security Standards.
|
||||
|
||||
For a step-by-step migration guide, see
|
||||
[Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp/).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## PodSecurityPolicy Spec
|
||||
|
||||
The fields enumerated in this table are part of the `PodSecurityPolicySpec`, which is specified
|
||||
under the `.spec` field path.
|
||||
|
||||
<table class="no-word-break">
|
||||
<caption style="display:none">Mapping PodSecurityPolicySpec fields to Pod Security Standards</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th><code>PodSecurityPolicySpec</code></th>
|
||||
<th>Type</th>
|
||||
<th>Pod Security Standards Equivalent</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>privileged</code></td>
|
||||
<td>Validating</td>
|
||||
<td><b>Baseline & Restricted</b>: <code>false</code> / undefined / nil</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>defaultAddCapabilities</code></td>
|
||||
<td>Mutating & Validating</td>
|
||||
<td>Requirements match <code>allowedCapabilities</code> below.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>allowedCapabilities</code></td>
|
||||
<td>Validating</td>
|
||||
<td>
|
||||
<p><b>Baseline</b>: subset of</p>
|
||||
<ul>
|
||||
<li><code>AUDIT_WRITE</code></li>
|
||||
<li><code>CHOWN</code></li>
|
||||
<li><code>DAC_OVERRIDE</code></li>
|
||||
<li><code>FOWNER</code></li>
|
||||
<li><code>FSETID</code></li>
|
||||
<li><code>KILL</code></li>
|
||||
<li><code>MKNOD</code></li>
|
||||
<li><code>NET_BIND_SERVICE</code></li>
|
||||
<li><code>SETFCAP</code></li>
|
||||
<li><code>SETGID</code></li>
|
||||
<li><code>SETPCAP</code></li>
|
||||
<li><code>SETUID</code></li>
|
||||
<li><code>SYS_CHROOT</code></li>
|
||||
</ul>
|
||||
<p><b>Restricted</b>: empty / undefined / nil OR a list containing <i>only</i> <code>NET_BIND_SERVICE</code>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>requiredDropCapabilities</code></td>
|
||||
<td>Mutating & Validating</td>
|
||||
<td>
|
||||
<p><b>Baseline</b>: no opinion</p>
|
||||
<p><b>Restricted</b>: must include <code>ALL</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>volumes</code></td>
|
||||
<td>Validating</td>
|
||||
<td>
|
||||
<p><b>Baseline</b>: anything except</p>
|
||||
<ul>
|
||||
<li><code>hostPath</code></li>
|
||||
<li><code>*</code></li>
|
||||
</ul>
|
||||
<p><b>Restricted</b>: subset of</p>
|
||||
<ul>
|
||||
<li><code>configMap</code></li>
|
||||
<li><code>csi</code></li>
|
||||
<li><code>downwardAPI</code></li>
|
||||
<li><code>emptyDir</code></li>
|
||||
<li><code>ephemeral</code></li>
|
||||
<li><code>persistentVolumeClaim</code></li>
|
||||
<li><code>projected</code></li>
|
||||
<li><code>secret</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>hostNetwork</code></td>
|
||||
<td>Validating</td>
|
||||
<td><b>Baseline & Restricted</b>: <code>false</code> / undefined / nil</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>hostPorts</code></td>
|
||||
<td>Validating</td>
|
||||
<td><b>Baseline & Restricted</b>: undefined / nil / empty</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>hostPID</code></td>
|
||||
<td>Validating</td>
|
||||
<td><b>Baseline & Restricted</b>: <code>false</code> / undefined / nil</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>hostIPC</code></td>
|
||||
<td>Validating</td>
|
||||
<td><b>Baseline & Restricted</b>: <code>false</code> / undefined / nil</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>seLinux</code></td>
|
||||
<td>Mutating & Validating</td>
|
||||
<td>
|
||||
<p><b>Baseline & Restricted</b>:
|
||||
<code>seLinux.rule</code> is <code>MustRunAs</code>, with the following <code>options</code></p>
|
||||
<ul>
|
||||
<li><code>user</code> is unset (<code>""</code> / undefined / nil)</li>
|
||||
<li><code>role</code> is unset (<code>""</code> / undefined / nil)</li>
|
||||
<li><code>type</code> is unset or one of: <code>container_t, container_init_t, container_kvm_t</code></li>
|
||||
<li><code>level</code> is anything</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>runAsUser</code></td>
|
||||
<td>Mutating & Validating</td>
|
||||
<td>
|
||||
<p><b>Baseline</b>: Anything</p>
|
||||
<p><b>Restricted</b>: <code>rule</code> is <code>MustRunAsNonRoot</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>runAsGroup</code></td>
|
||||
<td>Mutating (MustRunAs) & Validating</td>
|
||||
<td>
|
||||
<i>No opinion</i>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>supplementalGroups</code></td>
|
||||
<td>Mutating & Validating</td>
|
||||
<td>
|
||||
<i>No opinion</i>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>fsGroup</code></td>
|
||||
<td>Mutating & Validating</td>
|
||||
<td>
|
||||
<i>No opinion</i>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>readOnlyRootFilesystem</code></td>
|
||||
<td>Mutating & Validating</td>
|
||||
<td>
|
||||
<i>No opinion</i>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>defaultAllowPrivilegeEscalation</code></td>
|
||||
<td>Mutating</td>
|
||||
<td>
|
||||
<i>No opinion (non-validating)</i>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>allowPrivilegeEscalation</code></td>
|
||||
<td>Mutating & Validating</td>
|
||||
<td>
|
||||
<p><i>Only mutating if set to <code>false</code></i></p>
|
||||
<p><b>Baseline</b>: No opinion</p>
|
||||
<p><b>Restricted</b>: <code>false</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>allowedHostPaths</code></td>
|
||||
<td>Validating</td>
|
||||
<td><i>No opinion (volumes takes precedence)</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>allowedFlexVolumes</code></td>
|
||||
<td>Validating</td>
|
||||
<td><i>No opinion (volumes takes precedence)</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>allowedCSIDrivers</code></td>
|
||||
<td>Validating</td>
|
||||
<td><i>No opinion (volumes takes precedence)</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>allowedUnsafeSysctls</code></td>
|
||||
<td>Validating</td>
|
||||
<td><b>Baseline & Restricted</b>: undefined / nil / empty</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>forbiddenSysctls</code></td>
|
||||
<td>Validating</td>
|
||||
<td><i>No opinion</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>allowedProcMountTypes</code><br><i>(alpha feature)</i></td>
|
||||
<td>Validating</td>
|
||||
<td><b>Baseline & Restricted</b>: <code>["Default"]</code> OR undefined / nil / empty</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>runtimeClass</code><br><code> .defaultRuntimeClassName</code></td>
|
||||
<td>Mutating</td>
|
||||
<td><i>No opinion</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>runtimeClass</code><br><code> .allowedRuntimeClassNames</code></td>
|
||||
<td>Validating</td>
|
||||
<td><i>No opinion</i></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## PodSecurityPolicy annotations
|
||||
|
||||
The [annotations](/docs/concepts/overview/working-with-objects/annotations/) enumerated in this
|
||||
table can be specified under `.metadata.annotations` on the PodSecurityPolicy object.
|
||||
|
||||
<table class="no-word-break">
|
||||
<caption style="display:none">Mapping PodSecurityPolicy annotations to Pod Security Standards</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th><code>PSP Annotation</code></th>
|
||||
<th>Type</th>
|
||||
<th>Pod Security Standards Equivalent</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>seccomp.security.alpha.kubernetes.io</code><br><code>/defaultProfileName</code></td>
|
||||
<td>Mutating</td>
|
||||
<td><i>No opinion</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>seccomp.security.alpha.kubernetes.io</code><br><code>/allowedProfileNames</code></td>
|
||||
<td>Validating</td>
|
||||
<td>
|
||||
<p><b>Baseline</b>: <code>"runtime/default,"</code> <i>(Trailing comma to allow unset)</i></p>
|
||||
<p><b>Restricted</b>: <code>"runtime/default"</code> <i>(No trailing comma)</i></p>
|
||||
<p><i><code>localhost/*</code> values are also permitted for both Baseline & Restricted.</i></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>apparmor.security.beta.kubernetes.io</code><br><code>/defaultProfileName</code></td>
|
||||
<td>Mutating</td>
|
||||
<td><i>No opinion</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>apparmor.security.beta.kubernetes.io</code><br><code>/allowedProfileNames</code></td>
|
||||
<td>Validating</td>
|
||||
<td>
|
||||
<p><b>Baseline</b>: <code>"runtime/default,"</code> <i>(Trailing comma to allow unset)</i></p>
|
||||
<p><b>Restricted</b>: <code>"runtime/default"</code> <i>(No trailing comma)</i></p>
|
||||
<p><i><code>localhost/*</code> values are also permitted for both Baseline & Restricted.</i></p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -19,13 +19,13 @@ auto_generated: true
|
||||
## `Event` {#audit-k8s-io-v1-Event}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [EventList](#audit-k8s-io-v1-EventList)
|
||||
|
||||
|
||||
Event captures all the information that can be included in an API audit log.
|
||||
<p>Event captures all the information that can be included in an API audit log.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -34,152 +34,134 @@ Event captures all the information that can be included in an API audit log.
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>audit.k8s.io/v1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>Event</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>level</code> <B>[Required]</B><br/>
|
||||
<a href="#audit-k8s-io-v1-Level"><code>Level</code></a>
|
||||
</td>
|
||||
<td>
|
||||
AuditLevel at which event was generated</td>
|
||||
<p>AuditLevel at which event was generated</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>auditID</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/types#UID"><code>k8s.io/apimachinery/pkg/types.UID</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/types#UID"><code>k8s.io/apimachinery/pkg/types.UID</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Unique audit ID, generated for each request.</td>
|
||||
<p>Unique audit ID, generated for each request.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>stage</code> <B>[Required]</B><br/>
|
||||
<a href="#audit-k8s-io-v1-Stage"><code>Stage</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Stage of the request handling when this event instance was generated.</td>
|
||||
<p>Stage of the request handling when this event instance was generated.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>requestURI</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
RequestURI is the request URI as sent by the client to a server.</td>
|
||||
<p>RequestURI is the request URI as sent by the client to a server.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>verb</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Verb is the kubernetes verb associated with the request.
|
||||
For non-resource requests, this is the lower-cased HTTP method.</td>
|
||||
<p>Verb is the kubernetes verb associated with the request.
|
||||
For non-resource requests, this is the lower-cased HTTP method.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>user</code> <B>[Required]</B><br/>
|
||||
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#userinfo-v1-authentication"><code>authentication/v1.UserInfo</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Authenticated user information.</td>
|
||||
<p>Authenticated user information.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>impersonatedUser</code><br/>
|
||||
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#userinfo-v1-authentication"><code>authentication/v1.UserInfo</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Impersonated user information.</td>
|
||||
<p>Impersonated user information.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>sourceIPs</code><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
Source IPs, from where the request originated and intermediate proxies.</td>
|
||||
<p>Source IPs, from where the request originated and intermediate proxies.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>userAgent</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
UserAgent records the user agent string reported by the client.
|
||||
Note that the UserAgent is provided by the client, and must not be trusted.</td>
|
||||
<p>UserAgent records the user agent string reported by the client.
|
||||
Note that the UserAgent is provided by the client, and must not be trusted.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>objectRef</code><br/>
|
||||
<a href="#audit-k8s-io-v1-ObjectReference"><code>ObjectReference</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Object reference this request is targeted at.
|
||||
Does not apply for List-type requests, or non-resource requests.</td>
|
||||
<p>Object reference this request is targeted at.
|
||||
Does not apply for List-type requests, or non-resource requests.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>responseStatus</code><br/>
|
||||
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#status-v1-meta"><code>meta/v1.Status</code></a>
|
||||
</td>
|
||||
<td>
|
||||
The response status, populated even when the ResponseObject is not a Status type.
|
||||
<p>The response status, populated even when the ResponseObject is not a Status type.
|
||||
For successful responses, this will only include the Code and StatusSuccess.
|
||||
For non-status type error responses, this will be auto-populated with the error Message.</td>
|
||||
For non-status type error responses, this will be auto-populated with the error Message.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>requestObject</code><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/runtime#Unknown"><code>k8s.io/apimachinery/pkg/runtime.Unknown</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime#Unknown"><code>k8s.io/apimachinery/pkg/runtime.Unknown</code></a>
|
||||
</td>
|
||||
<td>
|
||||
API object from the request, in JSON format. The RequestObject is recorded as-is in the request
|
||||
<p>API object from the request, in JSON format. The RequestObject is recorded as-is in the request
|
||||
(possibly re-encoded as JSON), prior to version conversion, defaulting, admission or
|
||||
merging. It is an external versioned object type, and may not be a valid object on its own.
|
||||
Omitted for non-resource requests. Only logged at Request Level and higher.</td>
|
||||
Omitted for non-resource requests. Only logged at Request Level and higher.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>responseObject</code><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/runtime#Unknown"><code>k8s.io/apimachinery/pkg/runtime.Unknown</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime#Unknown"><code>k8s.io/apimachinery/pkg/runtime.Unknown</code></a>
|
||||
</td>
|
||||
<td>
|
||||
API object returned in the response, in JSON. The ResponseObject is recorded after conversion
|
||||
<p>API object returned in the response, in JSON. The ResponseObject is recorded after conversion
|
||||
to the external type, and serialized as JSON. Omitted for non-resource requests. Only logged
|
||||
at Response Level.</td>
|
||||
at Response Level.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>requestReceivedTimestamp</code><br/>
|
||||
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#microtime-v1-meta"><code>meta/v1.MicroTime</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Time the request reached the apiserver.</td>
|
||||
<p>Time the request reached the apiserver.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>stageTimestamp</code><br/>
|
||||
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#microtime-v1-meta"><code>meta/v1.MicroTime</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Time the request reached current audit stage.</td>
|
||||
<p>Time the request reached current audit stage.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>annotations</code><br/>
|
||||
<code>map[string]string</code>
|
||||
</td>
|
||||
<td>
|
||||
Annotations is an unstructured key value map stored with an audit event that may be set by
|
||||
<p>Annotations is an unstructured key value map stored with an audit event that may be set by
|
||||
plugins invoked in the request serving chain, including authentication, authorization and
|
||||
admission plugins. Note that these annotations are for the audit event, and do not correspond
|
||||
to the metadata.annotations of the submitted object. Keys should uniquely identify the informing
|
||||
component to avoid name collisions (e.g. podsecuritypolicy.admission.k8s.io/policy). Values
|
||||
should be short. Annotations are included in the Metadata level.</td>
|
||||
should be short. Annotations are included in the Metadata level.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@@ -187,10 +169,9 @@ should be short. Annotations are included in the Metadata level.</td>
|
||||
|
||||
|
||||
|
||||
<p>EventList is a list of audit Events.</p>
|
||||
|
||||
|
||||
EventList is a list of audit Events.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
@@ -198,41 +179,33 @@ EventList is a list of audit Events.
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>audit.k8s.io/v1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>EventList</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>metadata</code><br/>
|
||||
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#listmeta-v1-meta"><code>meta/v1.ListMeta</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>items</code> <B>[Required]</B><br/>
|
||||
<a href="#audit-k8s-io-v1-Event"><code>[]Event</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `Policy` {#audit-k8s-io-v1-Policy}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [PolicyList](#audit-k8s-io-v1-PolicyList)
|
||||
|
||||
|
||||
Policy defines the configuration of audit logging, and the rules for how different request
|
||||
categories are logged.
|
||||
<p>Policy defines the configuration of audit logging, and the rules for how different request
|
||||
categories are logged.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -241,50 +214,44 @@ categories are logged.
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>audit.k8s.io/v1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>Policy</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>metadata</code><br/>
|
||||
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#objectmeta-v1-meta"><code>meta/v1.ObjectMeta</code></a>
|
||||
</td>
|
||||
<td>
|
||||
ObjectMeta is included for interoperability with API infrastructure.Refer to the Kubernetes API documentation for the fields of the <code>metadata</code> field.</td>
|
||||
<p>ObjectMeta is included for interoperability with API infrastructure.</p>
|
||||
Refer to the Kubernetes API documentation for the fields of the <code>metadata</code> field.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>rules</code> <B>[Required]</B><br/>
|
||||
<a href="#audit-k8s-io-v1-PolicyRule"><code>[]PolicyRule</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Rules specify the audit Level a request should be recorded at.
|
||||
<p>Rules specify the audit Level a request should be recorded at.
|
||||
A request may match multiple rules, in which case the FIRST matching rule is used.
|
||||
The default audit level is None, but can be overridden by a catch-all rule at the end of the list.
|
||||
PolicyRules are strictly ordered.</td>
|
||||
PolicyRules are strictly ordered.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>omitStages</code><br/>
|
||||
<a href="#audit-k8s-io-v1-Stage"><code>[]Stage</code></a>
|
||||
</td>
|
||||
<td>
|
||||
OmitStages is a list of stages for which no events are created. Note that this can also
|
||||
be specified per rule in which case the union of both are omitted.</td>
|
||||
<p>OmitStages is a list of stages for which no events are created. Note that this can also
|
||||
be specified per rule in which case the union of both are omitted.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>omitManagedFields</code><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
OmitManagedFields indicates whether to omit the managed fields of the request
|
||||
<p>OmitManagedFields indicates whether to omit the managed fields of the request
|
||||
and response bodies from being written to the API audit log.
|
||||
This is used as a global default - a value of 'true' will omit the managed fileds,
|
||||
otherwise the managed fields will be included in the API audit log.
|
||||
Note that this can also be specified per rule in which case the value specified
|
||||
in a rule will override the global default.</td>
|
||||
in a rule will override the global default.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@@ -292,10 +259,9 @@ in a rule will override the global default.</td>
|
||||
|
||||
|
||||
|
||||
<p>PolicyList is a list of audit Policies.</p>
|
||||
|
||||
|
||||
PolicyList is a list of audit Policies.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
@@ -303,86 +269,71 @@ PolicyList is a list of audit Policies.
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>audit.k8s.io/v1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>PolicyList</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>metadata</code><br/>
|
||||
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#listmeta-v1-meta"><code>meta/v1.ListMeta</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>items</code> <B>[Required]</B><br/>
|
||||
<a href="#audit-k8s-io-v1-Policy"><code>[]Policy</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `GroupResources` {#audit-k8s-io-v1-GroupResources}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [PolicyRule](#audit-k8s-io-v1-PolicyRule)
|
||||
|
||||
|
||||
GroupResources represents resource kinds in an API group.
|
||||
<p>GroupResources represents resource kinds in an API group.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>group</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Group is the name of the API group that contains the resources.
|
||||
The empty string represents the core API group.</td>
|
||||
<p>Group is the name of the API group that contains the resources.
|
||||
The empty string represents the core API group.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>resources</code><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
Resources is a list of resources this rule applies to.
|
||||
|
||||
For example:
|
||||
<p>Resources is a list of resources this rule applies to.</p>
|
||||
<p>For example:
|
||||
'pods' matches pods.
|
||||
'pods/log' matches the log subresource of pods.
|
||||
'∗' matches all resources and their subresources.
|
||||
'pods/∗' matches all subresources of pods.
|
||||
'∗/scale' matches all scale subresources.
|
||||
|
||||
If wildcard is present, the validation rule will ensure resources do not
|
||||
overlap with each other.
|
||||
|
||||
An empty list implies all resources and subresources in this API groups apply.</td>
|
||||
'<em>' matches all resources and their subresources.
|
||||
'pods/</em>' matches all subresources of pods.
|
||||
'*/scale' matches all scale subresources.</p>
|
||||
<p>If wildcard is present, the validation rule will ensure resources do not
|
||||
overlap with each other.</p>
|
||||
<p>An empty list implies all resources and subresources in this API groups apply.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>resourceNames</code><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
ResourceNames is a list of resource instance names that the policy matches.
|
||||
<p>ResourceNames is a list of resource instance names that the policy matches.
|
||||
Using this field requires Resources to be specified.
|
||||
An empty list implies that every instance of the resource is matched.</td>
|
||||
An empty list implies that every instance of the resource is matched.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@@ -390,216 +341,189 @@ An empty list implies that every instance of the resource is matched.</td>
|
||||
|
||||
(Alias of `string`)
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [Event](#audit-k8s-io-v1-Event)
|
||||
|
||||
- [PolicyRule](#audit-k8s-io-v1-PolicyRule)
|
||||
|
||||
|
||||
Level defines the amount of information logged during auditing
|
||||
<p>Level defines the amount of information logged during auditing</p>
|
||||
|
||||
|
||||
|
||||
|
||||
## `ObjectReference` {#audit-k8s-io-v1-ObjectReference}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [Event](#audit-k8s-io-v1-Event)
|
||||
|
||||
|
||||
ObjectReference contains enough information to let you inspect or modify the referred object.
|
||||
<p>ObjectReference contains enough information to let you inspect or modify the referred object.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>resource</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>namespace</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>name</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>uid</code><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/types#UID"><code>k8s.io/apimachinery/pkg/types.UID</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/types#UID"><code>k8s.io/apimachinery/pkg/types.UID</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>apiGroup</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
APIGroup is the name of the API group that contains the referred object.
|
||||
The empty string represents the core API group.</td>
|
||||
<p>APIGroup is the name of the API group that contains the referred object.
|
||||
The empty string represents the core API group.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>apiVersion</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
APIVersion is the version of the API group that contains the referred object.</td>
|
||||
<p>APIVersion is the version of the API group that contains the referred object.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>resourceVersion</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>subresource</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `PolicyRule` {#audit-k8s-io-v1-PolicyRule}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [Policy](#audit-k8s-io-v1-Policy)
|
||||
|
||||
|
||||
PolicyRule maps requests based off metadata to an audit Level.
|
||||
Requests must match the rules of every field (an intersection of rules).
|
||||
<p>PolicyRule maps requests based off metadata to an audit Level.
|
||||
Requests must match the rules of every field (an intersection of rules).</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>level</code> <B>[Required]</B><br/>
|
||||
<a href="#audit-k8s-io-v1-Level"><code>Level</code></a>
|
||||
</td>
|
||||
<td>
|
||||
The Level that requests matching this rule are recorded at.</td>
|
||||
<p>The Level that requests matching this rule are recorded at.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>users</code><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
The users (by authenticated user name) this rule applies to.
|
||||
An empty list implies every user.</td>
|
||||
<p>The users (by authenticated user name) this rule applies to.
|
||||
An empty list implies every user.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>userGroups</code><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
The user groups this rule applies to. A user is considered matching
|
||||
<p>The user groups this rule applies to. A user is considered matching
|
||||
if it is a member of any of the UserGroups.
|
||||
An empty list implies every user group.</td>
|
||||
An empty list implies every user group.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>verbs</code><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
The verbs that match this rule.
|
||||
An empty list implies every verb.</td>
|
||||
<p>The verbs that match this rule.
|
||||
An empty list implies every verb.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>resources</code><br/>
|
||||
<a href="#audit-k8s-io-v1-GroupResources"><code>[]GroupResources</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Resources that this rule matches. An empty list implies all kinds in all API groups.</td>
|
||||
<p>Resources that this rule matches. An empty list implies all kinds in all API groups.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>namespaces</code><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
Namespaces that this rule matches.
|
||||
The empty string "" matches non-namespaced resources.
|
||||
An empty list implies every namespace.</td>
|
||||
<p>Namespaces that this rule matches.
|
||||
The empty string "" matches non-namespaced resources.
|
||||
An empty list implies every namespace.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>nonResourceURLs</code><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
NonResourceURLs is a set of URL paths that should be audited.
|
||||
∗s are allowed, but only as the full, final step in the path.
|
||||
<p>NonResourceURLs is a set of URL paths that should be audited.
|
||||
<em>s are allowed, but only as the full, final step in the path.
|
||||
Examples:
|
||||
"/metrics" - Log requests for apiserver metrics
|
||||
"/healthz∗" - Log all health checks</td>
|
||||
"/metrics" - Log requests for apiserver metrics
|
||||
"/healthz</em>" - Log all health checks</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>omitStages</code><br/>
|
||||
<a href="#audit-k8s-io-v1-Stage"><code>[]Stage</code></a>
|
||||
</td>
|
||||
<td>
|
||||
OmitStages is a list of stages for which no events are created. Note that this can also
|
||||
<p>OmitStages is a list of stages for which no events are created. Note that this can also
|
||||
be specified policy wide in which case the union of both are omitted.
|
||||
An empty list means no restrictions will apply.</td>
|
||||
An empty list means no restrictions will apply.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>omitManagedFields</code><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
OmitManagedFields indicates whether to omit the managed fields of the request
|
||||
and response bodies from being written to the API audit log.
|
||||
- a value of 'true' will drop the managed fields from the API audit log
|
||||
- a value of 'false' indicates that the managed fileds should be included
|
||||
in the API audit log
|
||||
<p>OmitManagedFields indicates whether to omit the managed fields of the request
|
||||
and response bodies from being written to the API audit log.</p>
|
||||
<ul>
|
||||
<li>a value of 'true' will drop the managed fields from the API audit log</li>
|
||||
<li>a value of 'false' indicates that the managed fileds should be included
|
||||
in the API audit log
|
||||
Note that the value, if specified, in this rule will override the global default
|
||||
If a value is not specified then the global default specified in
|
||||
Policy.OmitManagedFields will stand.</td>
|
||||
Policy.OmitManagedFields will stand.</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@@ -607,14 +531,17 @@ Policy.OmitManagedFields will stand.</td>
|
||||
|
||||
(Alias of `string`)
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [Event](#audit-k8s-io-v1-Event)
|
||||
|
||||
- [Policy](#audit-k8s-io-v1-Policy)
|
||||
|
||||
- [PolicyRule](#audit-k8s-io-v1-PolicyRule)
|
||||
|
||||
|
||||
Stage defines the stages in request handling that audit events may be generated.
|
||||
<p>Stage defines the stages in request handling that audit events may be generated.</p>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,7 +4,8 @@ content_type: tool-reference
|
||||
package: apiserver.config.k8s.io/v1
|
||||
auto_generated: true
|
||||
---
|
||||
Package v1 is the v1 version of the API.
|
||||
<p>Package v1 is the v1 version of the API.</p>
|
||||
|
||||
|
||||
## Resource Types
|
||||
|
||||
@@ -17,10 +18,9 @@ Package v1 is the v1 version of the API.
|
||||
|
||||
|
||||
|
||||
<p>AdmissionConfiguration provides versioned configuration for admission controllers.</p>
|
||||
|
||||
|
||||
AdmissionConfiguration provides versioned configuration for admission controllers.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
@@ -28,64 +28,57 @@ AdmissionConfiguration provides versioned configuration for admission controller
|
||||
<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>AdmissionConfiguration</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>plugins</code><br/>
|
||||
<a href="#apiserver-config-k8s-io-v1-AdmissionPluginConfiguration"><code>[]AdmissionPluginConfiguration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Plugins allows specifying a configuration per admission control plugin.</td>
|
||||
<p>Plugins allows specifying a configuration per admission control plugin.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `AdmissionPluginConfiguration` {#apiserver-config-k8s-io-v1-AdmissionPluginConfiguration}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [AdmissionConfiguration](#apiserver-config-k8s-io-v1-AdmissionConfiguration)
|
||||
|
||||
|
||||
AdmissionPluginConfiguration provides the configuration for a single plug-in.
|
||||
<p>AdmissionPluginConfiguration provides the configuration for a single plug-in.</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>
|
||||
Name is the name of the admission controller.
|
||||
It must match the registered admission plugin name.</td>
|
||||
<p>Name is the name of the admission controller.
|
||||
It must match the registered admission plugin name.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>path</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Path is the path to a configuration file that contains the plugin's
|
||||
configuration</td>
|
||||
<p>Path is the path to a configuration file that contains the plugin's
|
||||
configuration</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>configuration</code><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/runtime#Unknown"><code>k8s.io/apimachinery/pkg/runtime.Unknown</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime#Unknown"><code>k8s.io/apimachinery/pkg/runtime.Unknown</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Configuration is an embedded configuration object to be used as the plugin's
|
||||
configuration. If present, it will be used instead of the path to the configuration file.</td>
|
||||
<p>Configuration is an embedded configuration object to be used as the plugin's
|
||||
configuration. If present, it will be used instead of the path to the configuration file.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
@@ -4,7 +4,8 @@ content_type: tool-reference
|
||||
package: apiserver.config.k8s.io/v1
|
||||
auto_generated: true
|
||||
---
|
||||
Package v1 is the v1 version of the API.
|
||||
<p>Package v1 is the v1 version of the API.</p>
|
||||
|
||||
|
||||
## Resource Types
|
||||
|
||||
@@ -17,10 +18,9 @@ Package v1 is the v1 version of the API.
|
||||
|
||||
|
||||
|
||||
<p>WebhookAdmission provides configuration for the webhook admission controller.</p>
|
||||
|
||||
|
||||
WebhookAdmission provides configuration for the webhook admission controller.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
@@ -28,17 +28,14 @@ WebhookAdmission provides configuration for the webhook admission controller.
|
||||
<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>WebhookAdmission</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>kubeConfigFile</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
KubeConfigFile is the path to the kubeconfig file.</td>
|
||||
<p>KubeConfigFile is the path to the kubeconfig file.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
@@ -17,11 +17,10 @@ auto_generated: true
|
||||
|
||||
|
||||
|
||||
<p>ExecCredential is used by exec-based plugins to communicate credentials to
|
||||
HTTP transports.</p>
|
||||
|
||||
|
||||
ExecCredential is used by exec-based plugins to communicate credentials to
|
||||
HTTP transports.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
@@ -29,221 +28,202 @@ HTTP transports.
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>client.authentication.k8s.io/v1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>ExecCredential</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>spec</code> <B>[Required]</B><br/>
|
||||
<a href="#client-authentication-k8s-io-v1-ExecCredentialSpec"><code>ExecCredentialSpec</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Spec holds information passed to the plugin by the transport.</td>
|
||||
<p>Spec holds information passed to the plugin by the transport.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>status</code><br/>
|
||||
<a href="#client-authentication-k8s-io-v1-ExecCredentialStatus"><code>ExecCredentialStatus</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Status is filled in by the plugin and holds the credentials that the transport
|
||||
should use to contact the API.</td>
|
||||
<p>Status is filled in by the plugin and holds the credentials that the transport
|
||||
should use to contact the API.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `Cluster` {#client-authentication-k8s-io-v1-Cluster}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [ExecCredentialSpec](#client-authentication-k8s-io-v1-ExecCredentialSpec)
|
||||
|
||||
|
||||
Cluster contains information to allow an exec plugin to communicate
|
||||
with the kubernetes cluster being authenticated to.
|
||||
|
||||
To ensure that this struct contains everything someone would need to communicate
|
||||
<p>Cluster contains information to allow an exec plugin to communicate
|
||||
with the kubernetes cluster being authenticated to.</p>
|
||||
<p>To ensure that this struct contains everything someone would need to communicate
|
||||
with a kubernetes cluster (just like they would via a kubeconfig), the fields
|
||||
should shadow "k8s.io/client-go/tools/clientcmd/api/v1".Cluster, with the exception
|
||||
of CertificateAuthority, since CA data will always be passed to the plugin as bytes.
|
||||
should shadow "k8s.io/client-go/tools/clientcmd/api/v1".Cluster, with the exception
|
||||
of CertificateAuthority, since CA data will always be passed to the plugin as bytes.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>server</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Server is the address of the kubernetes cluster (https://hostname:port).</td>
|
||||
<p>Server is the address of the kubernetes cluster (https://hostname:port).</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>tls-server-name</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
TLSServerName is passed to the server for SNI and is used in the client to
|
||||
<p>TLSServerName is passed to the server for SNI and is used in the client to
|
||||
check server certificates against. If ServerName is empty, the hostname
|
||||
used to contact the server is used.</td>
|
||||
used to contact the server is used.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>insecure-skip-tls-verify</code><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
InsecureSkipTLSVerify skips the validity check for the server's certificate.
|
||||
This will make your HTTPS connections insecure.</td>
|
||||
<p>InsecureSkipTLSVerify skips the validity check for the server's certificate.
|
||||
This will make your HTTPS connections insecure.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>certificate-authority-data</code><br/>
|
||||
<code>[]byte</code>
|
||||
</td>
|
||||
<td>
|
||||
CAData contains PEM-encoded certificate authority certificates.
|
||||
If empty, system roots should be used.</td>
|
||||
<p>CAData contains PEM-encoded certificate authority certificates.
|
||||
If empty, system roots should be used.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>proxy-url</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
ProxyURL is the URL to the proxy to be used for all requests to this
|
||||
cluster.</td>
|
||||
<p>ProxyURL is the URL to the proxy to be used for all requests to this
|
||||
cluster.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>config</code><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/runtime/#RawExtension"><code>k8s.io/apimachinery/pkg/runtime.RawExtension</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime/#RawExtension"><code>k8s.io/apimachinery/pkg/runtime.RawExtension</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Config holds additional config data that is specific to the exec
|
||||
plugin with regards to the cluster being authenticated to.
|
||||
|
||||
This data is sourced from the clientcmd Cluster object's
|
||||
extensions[client.authentication.k8s.io/exec] field:
|
||||
|
||||
clusters:
|
||||
- name: my-cluster
|
||||
cluster:
|
||||
...
|
||||
extensions:
|
||||
- name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
|
||||
extension:
|
||||
audience: 06e3fbd18de8 # arbitrary config
|
||||
|
||||
In some environments, the user config may be exactly the same across many clusters
|
||||
<p>Config holds additional config data that is specific to the exec
|
||||
plugin with regards to the cluster being authenticated to.</p>
|
||||
<p>This data is sourced from the clientcmd Cluster object's
|
||||
extensions[client.authentication.k8s.io/exec] field:</p>
|
||||
<p>clusters:</p>
|
||||
<ul>
|
||||
<li>name: my-cluster
|
||||
cluster:
|
||||
...
|
||||
extensions:
|
||||
<ul>
|
||||
<li>name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
|
||||
extension:
|
||||
audience: 06e3fbd18de8 # arbitrary config</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>In some environments, the user config may be exactly the same across many clusters
|
||||
(i.e. call this exec plugin) minus some details that are specific to each cluster
|
||||
such as the audience. This field allows the per cluster config to be directly
|
||||
specified with the cluster info. Using this field to store secret data is not
|
||||
recommended as one of the prime benefits of exec plugins is that no secrets need
|
||||
to be stored directly in the kubeconfig.</td>
|
||||
to be stored directly in the kubeconfig.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `ExecCredentialSpec` {#client-authentication-k8s-io-v1-ExecCredentialSpec}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [ExecCredential](#client-authentication-k8s-io-v1-ExecCredential)
|
||||
|
||||
|
||||
ExecCredentialSpec holds request and runtime specific information provided by
|
||||
the transport.
|
||||
<p>ExecCredentialSpec holds request and runtime specific information provided by
|
||||
the transport.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>cluster</code><br/>
|
||||
<a href="#client-authentication-k8s-io-v1-Cluster"><code>Cluster</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Cluster contains information to allow an exec plugin to communicate with the
|
||||
<p>Cluster contains information to allow an exec plugin to communicate with the
|
||||
kubernetes cluster being authenticated to. Note that Cluster is non-nil only
|
||||
when provideClusterInfo is set to true in the exec provider config (i.e.,
|
||||
ExecConfig.ProvideClusterInfo).</td>
|
||||
ExecConfig.ProvideClusterInfo).</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>interactive</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
Interactive declares whether stdin has been passed to this exec plugin.</td>
|
||||
<p>Interactive declares whether stdin has been passed to this exec plugin.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `ExecCredentialStatus` {#client-authentication-k8s-io-v1-ExecCredentialStatus}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [ExecCredential](#client-authentication-k8s-io-v1-ExecCredential)
|
||||
|
||||
|
||||
ExecCredentialStatus holds credentials for the transport to use.
|
||||
|
||||
Token and ClientKeyData are sensitive fields. This data should only be
|
||||
<p>ExecCredentialStatus holds credentials for the transport to use.</p>
|
||||
<p>Token and ClientKeyData are sensitive fields. This data should only be
|
||||
transmitted in-memory between client and exec plugin process. Exec plugin
|
||||
itself should at least be protected via file permissions.
|
||||
itself should at least be protected via file permissions.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>expirationTimestamp</code><br/>
|
||||
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#time-v1-meta"><code>meta/v1.Time</code></a>
|
||||
</td>
|
||||
<td>
|
||||
ExpirationTimestamp indicates a time when the provided credentials expire.</td>
|
||||
<p>ExpirationTimestamp indicates a time when the provided credentials expire.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>token</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Token is a bearer token used by the client for request authentication.</td>
|
||||
<p>Token is a bearer token used by the client for request authentication.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>clientCertificateData</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
PEM-encoded client TLS certificates (including intermediates, if any).</td>
|
||||
<p>PEM-encoded client TLS certificates (including intermediates, if any).</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>clientKeyData</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
PEM-encoded private key for the above certificate.</td>
|
||||
<p>PEM-encoded private key for the above certificate.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
@@ -17,8 +17,9 @@ auto_generated: true
|
||||
|
||||
|
||||
|
||||
ExecCredential is used by exec-based plugins to communicate credentials to
|
||||
HTTP transports.
|
||||
<p>ExecCredential is used by exec-based plugins to communicate credentials to
|
||||
HTTP transports.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -32,15 +33,15 @@ HTTP transports.
|
||||
<a href="#client-authentication-k8s-io-v1beta1-ExecCredentialSpec"><code>ExecCredentialSpec</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Spec holds information passed to the plugin by the transport.
|
||||
<p>Spec holds information passed to the plugin by the transport.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>status</code><br/>
|
||||
<a href="#client-authentication-k8s-io-v1beta1-ExecCredentialStatus"><code>ExecCredentialStatus</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Status is filled in by the plugin and holds the credentials that the transport
|
||||
should use to contact the API.
|
||||
<p>Status is filled in by the plugin and holds the credentials that the transport
|
||||
should use to contact the API.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -53,13 +54,14 @@ should use to contact the API.
|
||||
|
||||
- [ExecCredentialSpec](#client-authentication-k8s-io-v1beta1-ExecCredentialSpec)
|
||||
|
||||
Cluster contains information to allow an exec plugin to communicate
|
||||
with the kubernetes cluster being authenticated to.
|
||||
|
||||
To ensure that this struct contains everything someone would need to communicate
|
||||
<p>Cluster contains information to allow an exec plugin to communicate
|
||||
with the kubernetes cluster being authenticated to.</p>
|
||||
<p>To ensure that this struct contains everything someone would need to communicate
|
||||
with a kubernetes cluster (just like they would via a kubeconfig), the fields
|
||||
should shadow "k8s.io/client-go/tools/clientcmd/api/v1".Cluster, with the exception
|
||||
of CertificateAuthority, since CA data will always be passed to the plugin as bytes.
|
||||
should shadow "k8s.io/client-go/tools/clientcmd/api/v1".Cluster, with the exception
|
||||
of CertificateAuthority, since CA data will always be passed to the plugin as bytes.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -70,67 +72,69 @@ of CertificateAuthority, since CA data will always be passed to the plugin as by
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Server is the address of the kubernetes cluster (https://hostname:port).
|
||||
<p>Server is the address of the kubernetes cluster (https://hostname:port).</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>tls-server-name</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
TLSServerName is passed to the server for SNI and is used in the client to
|
||||
<p>TLSServerName is passed to the server for SNI and is used in the client to
|
||||
check server certificates against. If ServerName is empty, the hostname
|
||||
used to contact the server is used.
|
||||
used to contact the server is used.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>insecure-skip-tls-verify</code><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
InsecureSkipTLSVerify skips the validity check for the server's certificate.
|
||||
This will make your HTTPS connections insecure.
|
||||
<p>InsecureSkipTLSVerify skips the validity check for the server's certificate.
|
||||
This will make your HTTPS connections insecure.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>certificate-authority-data</code><br/>
|
||||
<code>[]byte</code>
|
||||
</td>
|
||||
<td>
|
||||
CAData contains PEM-encoded certificate authority certificates.
|
||||
If empty, system roots should be used.
|
||||
<p>CAData contains PEM-encoded certificate authority certificates.
|
||||
If empty, system roots should be used.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>proxy-url</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
ProxyURL is the URL to the proxy to be used for all requests to this
|
||||
cluster.
|
||||
<p>ProxyURL is the URL to the proxy to be used for all requests to this
|
||||
cluster.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>config</code><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/runtime/#RawExtension"><code>k8s.io/apimachinery/pkg/runtime.RawExtension</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime/#RawExtension"><code>k8s.io/apimachinery/pkg/runtime.RawExtension</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Config holds additional config data that is specific to the exec
|
||||
plugin with regards to the cluster being authenticated to.
|
||||
|
||||
This data is sourced from the clientcmd Cluster object's
|
||||
extensions[client.authentication.k8s.io/exec] field:
|
||||
|
||||
clusters:
|
||||
- name: my-cluster
|
||||
cluster:
|
||||
...
|
||||
extensions:
|
||||
- name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
|
||||
extension:
|
||||
audience: 06e3fbd18de8 # arbitrary config
|
||||
|
||||
In some environments, the user config may be exactly the same across many clusters
|
||||
<p>Config holds additional config data that is specific to the exec
|
||||
plugin with regards to the cluster being authenticated to.</p>
|
||||
<p>This data is sourced from the clientcmd Cluster object's
|
||||
extensions[client.authentication.k8s.io/exec] field:</p>
|
||||
<p>clusters:</p>
|
||||
<ul>
|
||||
<li>name: my-cluster
|
||||
cluster:
|
||||
...
|
||||
extensions:
|
||||
<ul>
|
||||
<li>name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
|
||||
extension:
|
||||
audience: 06e3fbd18de8 # arbitrary config</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>In some environments, the user config may be exactly the same across many clusters
|
||||
(i.e. call this exec plugin) minus some details that are specific to each cluster
|
||||
such as the audience. This field allows the per cluster config to be directly
|
||||
specified with the cluster info. Using this field to store secret data is not
|
||||
recommended as one of the prime benefits of exec plugins is that no secrets need
|
||||
to be stored directly in the kubeconfig.
|
||||
to be stored directly in the kubeconfig.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -143,8 +147,10 @@ to be stored directly in the kubeconfig.
|
||||
|
||||
- [ExecCredential](#client-authentication-k8s-io-v1beta1-ExecCredential)
|
||||
|
||||
ExecCredentialSpec holds request and runtime specific information provided by
|
||||
the transport.
|
||||
|
||||
<p>ExecCredentialSpec holds request and runtime specific information provided by
|
||||
the transport.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -155,17 +161,17 @@ the transport.
|
||||
<a href="#client-authentication-k8s-io-v1beta1-Cluster"><code>Cluster</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Cluster contains information to allow an exec plugin to communicate with the
|
||||
<p>Cluster contains information to allow an exec plugin to communicate with the
|
||||
kubernetes cluster being authenticated to. Note that Cluster is non-nil only
|
||||
when provideClusterInfo is set to true in the exec provider config (i.e.,
|
||||
ExecConfig.ProvideClusterInfo).
|
||||
ExecConfig.ProvideClusterInfo).</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>interactive</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
Interactive declares whether stdin has been passed to this exec plugin.
|
||||
<p>Interactive declares whether stdin has been passed to this exec plugin.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -178,11 +184,12 @@ ExecConfig.ProvideClusterInfo).
|
||||
|
||||
- [ExecCredential](#client-authentication-k8s-io-v1beta1-ExecCredential)
|
||||
|
||||
ExecCredentialStatus holds credentials for the transport to use.
|
||||
|
||||
Token and ClientKeyData are sensitive fields. This data should only be
|
||||
<p>ExecCredentialStatus holds credentials for the transport to use.</p>
|
||||
<p>Token and ClientKeyData are sensitive fields. This data should only be
|
||||
transmitted in-memory between client and exec plugin process. Exec plugin
|
||||
itself should at least be protected via file permissions.
|
||||
itself should at least be protected via file permissions.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -193,28 +200,28 @@ itself should at least be protected via file permissions.
|
||||
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#time-v1-meta"><code>meta/v1.Time</code></a>
|
||||
</td>
|
||||
<td>
|
||||
ExpirationTimestamp indicates a time when the provided credentials expire.
|
||||
<p>ExpirationTimestamp indicates a time when the provided credentials expire.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>token</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Token is a bearer token used by the client for request authentication.
|
||||
<p>Token is a bearer token used by the client for request authentication.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>clientCertificateData</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
PEM-encoded client TLS certificates (including intermediates, if any).
|
||||
<p>PEM-encoded client TLS certificates (including intermediates, if any).</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>clientKeyData</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
PEM-encoded private key for the above certificate.
|
||||
<p>PEM-encoded private key for the above certificate.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
||||
@@ -17,8 +17,9 @@ auto_generated: true
|
||||
|
||||
|
||||
|
||||
KubeProxyConfiguration contains everything necessary to configure the
|
||||
Kubernetes proxy server.
|
||||
<p>KubeProxyConfiguration contains everything necessary to configure the
|
||||
Kubernetes proxy server.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -32,164 +33,164 @@ Kubernetes proxy server.
|
||||
<code>map[string]bool</code>
|
||||
</td>
|
||||
<td>
|
||||
featureGates is a map of feature names to bools that enable or disable alpha/experimental features.
|
||||
<p>featureGates is a map of feature names to bools that enable or disable alpha/experimental features.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>bindAddress</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
bindAddress is the IP address for the proxy server to serve on (set to 0.0.0.0
|
||||
for all interfaces)
|
||||
<p>bindAddress is the IP address for the proxy server to serve on (set to 0.0.0.0
|
||||
for all interfaces)</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>healthzBindAddress</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
healthzBindAddress is the IP address and port for the health check server to serve on,
|
||||
defaulting to 0.0.0.0:10256
|
||||
<p>healthzBindAddress is the IP address and port for the health check server to serve on,
|
||||
defaulting to 0.0.0.0:10256</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>metricsBindAddress</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
metricsBindAddress is the IP address and port for the metrics server to serve on,
|
||||
defaulting to 127.0.0.1:10249 (set to 0.0.0.0 for all interfaces)
|
||||
<p>metricsBindAddress is the IP address and port for the metrics server to serve on,
|
||||
defaulting to 127.0.0.1:10249 (set to 0.0.0.0 for all interfaces)</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>bindAddressHardFail</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
bindAddressHardFail, if true, kube-proxy will treat failure to bind to a port as fatal and exit
|
||||
<p>bindAddressHardFail, if true, kube-proxy will treat failure to bind to a port as fatal and exit</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>enableProfiling</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
enableProfiling enables profiling via web interface on /debug/pprof handler.
|
||||
Profiling handlers will be handled by metrics server.
|
||||
<p>enableProfiling enables profiling via web interface on /debug/pprof handler.
|
||||
Profiling handlers will be handled by metrics server.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>clusterCIDR</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
clusterCIDR is the CIDR range of the pods in the cluster. It is used to
|
||||
<p>clusterCIDR is the CIDR range of the pods in the cluster. It is used to
|
||||
bridge traffic coming from outside of the cluster. If not provided,
|
||||
no off-cluster bridging will be performed.
|
||||
no off-cluster bridging will be performed.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>hostnameOverride</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
hostnameOverride, if non-empty, will be used as the identity instead of the actual hostname.
|
||||
<p>hostnameOverride, if non-empty, will be used as the identity instead of the actual hostname.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>clientConnection</code> <B>[Required]</B><br/>
|
||||
<a href="#ClientConnectionConfiguration"><code>ClientConnectionConfiguration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
clientConnection specifies the kubeconfig file and client connection settings for the proxy
|
||||
server to use when communicating with the apiserver.
|
||||
<p>clientConnection specifies the kubeconfig file and client connection settings for the proxy
|
||||
server to use when communicating with the apiserver.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>iptables</code> <B>[Required]</B><br/>
|
||||
<a href="#kubeproxy-config-k8s-io-v1alpha1-KubeProxyIPTablesConfiguration"><code>KubeProxyIPTablesConfiguration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
iptables contains iptables-related configuration options.
|
||||
<p>iptables contains iptables-related configuration options.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>ipvs</code> <B>[Required]</B><br/>
|
||||
<a href="#kubeproxy-config-k8s-io-v1alpha1-KubeProxyIPVSConfiguration"><code>KubeProxyIPVSConfiguration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
ipvs contains ipvs-related configuration options.
|
||||
<p>ipvs contains ipvs-related configuration options.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>oomScoreAdj</code> <B>[Required]</B><br/>
|
||||
<code>int32</code>
|
||||
</td>
|
||||
<td>
|
||||
oomScoreAdj is the oom-score-adj value for kube-proxy process. Values must be within
|
||||
the range [-1000, 1000]
|
||||
<p>oomScoreAdj is the oom-score-adj value for kube-proxy process. Values must be within
|
||||
the range [-1000, 1000]</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>mode</code> <B>[Required]</B><br/>
|
||||
<a href="#kubeproxy-config-k8s-io-v1alpha1-ProxyMode"><code>ProxyMode</code></a>
|
||||
</td>
|
||||
<td>
|
||||
mode specifies which proxy mode to use.
|
||||
<p>mode specifies which proxy mode to use.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>portRange</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
portRange is the range of host ports (beginPort-endPort, inclusive) that may be consumed
|
||||
in order to proxy service traffic. If unspecified (0-0) then ports will be randomly chosen.
|
||||
<p>portRange is the range of host ports (beginPort-endPort, inclusive) that may be consumed
|
||||
in order to proxy service traffic. If unspecified (0-0) then ports will be randomly chosen.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>udpIdleTimeout</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
udpIdleTimeout is how long an idle UDP connection will be kept open (e.g. '250ms', '2s').
|
||||
Must be greater than 0. Only applicable for proxyMode=userspace.
|
||||
<p>udpIdleTimeout is how long an idle UDP connection will be kept open (e.g. '250ms', '2s').
|
||||
Must be greater than 0. Only applicable for proxyMode=userspace.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>conntrack</code> <B>[Required]</B><br/>
|
||||
<a href="#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConntrackConfiguration"><code>KubeProxyConntrackConfiguration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
conntrack contains conntrack-related configuration options.
|
||||
<p>conntrack contains conntrack-related configuration options.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>configSyncPeriod</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
configSyncPeriod is how often configuration from the apiserver is refreshed. Must be greater
|
||||
than 0.
|
||||
<p>configSyncPeriod is how often configuration from the apiserver is refreshed. Must be greater
|
||||
than 0.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>nodePortAddresses</code> <B>[Required]</B><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
nodePortAddresses is the --nodeport-addresses value for kube-proxy process. Values must be valid
|
||||
<p>nodePortAddresses is the --nodeport-addresses value for kube-proxy process. Values must be valid
|
||||
IP blocks. These values are as a parameter to select the interfaces where nodeport works.
|
||||
In case someone would like to expose a service on localhost for local visit and some other interfaces for
|
||||
particular purpose, a list of IP blocks would do that.
|
||||
If set it to "127.0.0.0/8", kube-proxy will only select the loopback interface for NodePort.
|
||||
If set it to "127.0.0.0/8", kube-proxy will only select the loopback interface for NodePort.
|
||||
If set it to a non-zero IP block, kube-proxy will filter that down to just the IPs that applied to the node.
|
||||
An empty string slice is meant to select all network interfaces.
|
||||
An empty string slice is meant to select all network interfaces.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>winkernel</code> <B>[Required]</B><br/>
|
||||
<a href="#kubeproxy-config-k8s-io-v1alpha1-KubeProxyWinkernelConfiguration"><code>KubeProxyWinkernelConfiguration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
winkernel contains winkernel-related configuration options.
|
||||
<p>winkernel contains winkernel-related configuration options.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>showHiddenMetricsForVersion</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
ShowHiddenMetricsForVersion is the version for which you want to show hidden metrics.
|
||||
<p>ShowHiddenMetricsForVersion is the version for which you want to show hidden metrics.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>detectLocalMode</code> <B>[Required]</B><br/>
|
||||
<a href="#kubeproxy-config-k8s-io-v1alpha1-LocalMode"><code>LocalMode</code></a>
|
||||
</td>
|
||||
<td>
|
||||
DetectLocalMode determines mode to use for detecting local traffic, defaults to LocalModeClusterCIDR
|
||||
<p>DetectLocalMode determines mode to use for detecting local traffic, defaults to LocalModeClusterCIDR</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -202,8 +203,10 @@ An empty string slice is meant to select all network interfaces.
|
||||
|
||||
- [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration)
|
||||
|
||||
KubeProxyConntrackConfiguration contains conntrack settings for
|
||||
the Kubernetes proxy server.
|
||||
|
||||
<p>KubeProxyConntrackConfiguration contains conntrack settings for
|
||||
the Kubernetes proxy server.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -214,33 +217,33 @@ the Kubernetes proxy server.
|
||||
<code>int32</code>
|
||||
</td>
|
||||
<td>
|
||||
maxPerCore is the maximum number of NAT connections to track
|
||||
per CPU core (0 to leave the limit as-is and ignore min).
|
||||
<p>maxPerCore is the maximum number of NAT connections to track
|
||||
per CPU core (0 to leave the limit as-is and ignore min).</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>min</code> <B>[Required]</B><br/>
|
||||
<code>int32</code>
|
||||
</td>
|
||||
<td>
|
||||
min is the minimum value of connect-tracking records to allocate,
|
||||
regardless of conntrackMaxPerCore (set maxPerCore=0 to leave the limit as-is).
|
||||
<p>min is the minimum value of connect-tracking records to allocate,
|
||||
regardless of conntrackMaxPerCore (set maxPerCore=0 to leave the limit as-is).</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>tcpEstablishedTimeout</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
tcpEstablishedTimeout is how long an idle TCP connection will be kept open
|
||||
(e.g. '2s'). Must be greater than 0 to set.
|
||||
<p>tcpEstablishedTimeout is how long an idle TCP connection will be kept open
|
||||
(e.g. '2s'). Must be greater than 0 to set.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>tcpCloseWaitTimeout</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
tcpCloseWaitTimeout is how long an idle conntrack entry
|
||||
<p>tcpCloseWaitTimeout is how long an idle conntrack entry
|
||||
in CLOSE_WAIT state will remain in the conntrack
|
||||
table. (e.g. '60s'). Must be greater than 0 to set.
|
||||
table. (e.g. '60s'). Must be greater than 0 to set.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -253,8 +256,10 @@ table. (e.g. '60s'). Must be greater than 0 to set.
|
||||
|
||||
- [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration)
|
||||
|
||||
KubeProxyIPTablesConfiguration contains iptables-related configuration
|
||||
details for the Kubernetes proxy server.
|
||||
|
||||
<p>KubeProxyIPTablesConfiguration contains iptables-related configuration
|
||||
details for the Kubernetes proxy server.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -265,31 +270,31 @@ details for the Kubernetes proxy server.
|
||||
<code>int32</code>
|
||||
</td>
|
||||
<td>
|
||||
masqueradeBit is the bit of the iptables fwmark space to use for SNAT if using
|
||||
the pure iptables proxy mode. Values must be within the range [0, 31].
|
||||
<p>masqueradeBit is the bit of the iptables fwmark space to use for SNAT if using
|
||||
the pure iptables proxy mode. Values must be within the range [0, 31].</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>masqueradeAll</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
masqueradeAll tells kube-proxy to SNAT everything if using the pure iptables proxy mode.
|
||||
<p>masqueradeAll tells kube-proxy to SNAT everything if using the pure iptables proxy mode.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>syncPeriod</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
syncPeriod is the period that iptables rules are refreshed (e.g. '5s', '1m',
|
||||
'2h22m'). Must be greater than 0.
|
||||
<p>syncPeriod is the period that iptables rules are refreshed (e.g. '5s', '1m',
|
||||
'2h22m'). Must be greater than 0.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>minSyncPeriod</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
minSyncPeriod is the minimum period that iptables rules are refreshed (e.g. '5s', '1m',
|
||||
'2h22m').
|
||||
<p>minSyncPeriod is the minimum period that iptables rules are refreshed (e.g. '5s', '1m',
|
||||
'2h22m').</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -302,8 +307,10 @@ the pure iptables proxy mode. Values must be within the range [0, 31].
|
||||
|
||||
- [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration)
|
||||
|
||||
KubeProxyIPVSConfiguration contains ipvs-related configuration
|
||||
details for the Kubernetes proxy server.
|
||||
|
||||
<p>KubeProxyIPVSConfiguration contains ipvs-related configuration
|
||||
details for the Kubernetes proxy server.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -311,66 +318,66 @@ details for the Kubernetes proxy server.
|
||||
|
||||
|
||||
<tr><td><code>syncPeriod</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
syncPeriod is the period that ipvs rules are refreshed (e.g. '5s', '1m',
|
||||
'2h22m'). Must be greater than 0.
|
||||
<p>syncPeriod is the period that ipvs rules are refreshed (e.g. '5s', '1m',
|
||||
'2h22m'). Must be greater than 0.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>minSyncPeriod</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
minSyncPeriod is the minimum period that ipvs rules are refreshed (e.g. '5s', '1m',
|
||||
'2h22m').
|
||||
<p>minSyncPeriod is the minimum period that ipvs rules are refreshed (e.g. '5s', '1m',
|
||||
'2h22m').</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>scheduler</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
ipvs scheduler
|
||||
<p>ipvs scheduler</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>excludeCIDRs</code> <B>[Required]</B><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
excludeCIDRs is a list of CIDR's which the ipvs proxier should not touch
|
||||
when cleaning up ipvs services.
|
||||
<p>excludeCIDRs is a list of CIDR's which the ipvs proxier should not touch
|
||||
when cleaning up ipvs services.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>strictARP</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
strict ARP configure arp_ignore and arp_announce to avoid answering ARP queries
|
||||
from kube-ipvs0 interface
|
||||
<p>strict ARP configure arp_ignore and arp_announce to avoid answering ARP queries
|
||||
from kube-ipvs0 interface</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>tcpTimeout</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
tcpTimeout is the timeout value used for idle IPVS TCP sessions.
|
||||
The default value is 0, which preserves the current timeout value on the system.
|
||||
<p>tcpTimeout is the timeout value used for idle IPVS TCP sessions.
|
||||
The default value is 0, which preserves the current timeout value on the system.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>tcpFinTimeout</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
tcpFinTimeout is the timeout value used for IPVS TCP sessions after receiving a FIN.
|
||||
The default value is 0, which preserves the current timeout value on the system.
|
||||
<p>tcpFinTimeout is the timeout value used for IPVS TCP sessions after receiving a FIN.
|
||||
The default value is 0, which preserves the current timeout value on the system.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>udpTimeout</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
udpTimeout is the timeout value used for IPVS UDP packets.
|
||||
The default value is 0, which preserves the current timeout value on the system.
|
||||
<p>udpTimeout is the timeout value used for IPVS UDP packets.
|
||||
The default value is 0, which preserves the current timeout value on the system.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -383,8 +390,10 @@ The default value is 0, which preserves the current timeout value on the system.
|
||||
|
||||
- [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration)
|
||||
|
||||
KubeProxyWinkernelConfiguration contains Windows/HNS settings for
|
||||
the Kubernetes proxy server.
|
||||
|
||||
<p>KubeProxyWinkernelConfiguration contains Windows/HNS settings for
|
||||
the Kubernetes proxy server.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -395,24 +404,24 @@ the Kubernetes proxy server.
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
networkName is the name of the network kube-proxy will use
|
||||
to create endpoints and policies
|
||||
<p>networkName is the name of the network kube-proxy will use
|
||||
to create endpoints and policies</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>sourceVip</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
sourceVip is the IP address of the source VIP endoint used for
|
||||
NAT when loadbalancing
|
||||
<p>sourceVip is the IP address of the source VIP endoint used for
|
||||
NAT when loadbalancing</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>enableDSR</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
enableDSR tells kube-proxy whether HNS policies should be created
|
||||
with DSR
|
||||
<p>enableDSR tells kube-proxy whether HNS policies should be created
|
||||
with DSR</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -421,36 +430,38 @@ with DSR
|
||||
## `LocalMode` {#kubeproxy-config-k8s-io-v1alpha1-LocalMode}
|
||||
|
||||
(Alias of `string`)
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration)
|
||||
|
||||
LocalMode represents modes to detect local traffic from the node
|
||||
|
||||
<p>LocalMode represents modes to detect local traffic from the node</p>
|
||||
|
||||
|
||||
|
||||
|
||||
## `ProxyMode` {#kubeproxy-config-k8s-io-v1alpha1-ProxyMode}
|
||||
|
||||
(Alias of `string`)
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration)
|
||||
|
||||
ProxyMode represents modes used by the Kubernetes proxy server.
|
||||
|
||||
Currently, three modes of proxy are available in Linux platform: 'userspace' (older, going to be EOL), 'iptables'
|
||||
(newer, faster), 'ipvs'(newest, better in performance and scalability).
|
||||
|
||||
Two modes of proxy are available in Windows platform: 'userspace'(older, stable) and 'kernelspace' (newer, faster).
|
||||
|
||||
In Linux platform, if proxy mode is blank, use the best-available proxy (currently iptables, but may change in the
|
||||
<p>ProxyMode represents modes used by the Kubernetes proxy server.</p>
|
||||
<p>Currently, three modes of proxy are available in Linux platform: 'userspace' (older, going to be EOL), 'iptables'
|
||||
(newer, faster), 'ipvs'(newest, better in performance and scalability).</p>
|
||||
<p>Two modes of proxy are available in Windows platform: 'userspace'(older, stable) and 'kernelspace' (newer, faster).</p>
|
||||
<p>In Linux platform, if proxy mode is blank, use the best-available proxy (currently iptables, but may change in the
|
||||
future). If the iptables proxy is selected, regardless of how, but the system's kernel or iptables versions are
|
||||
insufficient, this always falls back to the userspace proxy. IPVS mode will be enabled when proxy mode is set to 'ipvs',
|
||||
and the fall back path is firstly iptables and then userspace.
|
||||
|
||||
In Windows platform, if proxy mode is blank, use the best-available proxy (currently userspace, but may change in the
|
||||
and the fall back path is firstly iptables and then userspace.</p>
|
||||
<p>In Windows platform, if proxy mode is blank, use the best-available proxy (currently userspace, but may change in the
|
||||
future). If winkernel proxy is selected, regardless of how, but the Windows kernel can't support this mode of proxy,
|
||||
this always falls back to the userspace proxy.
|
||||
this always falls back to the userspace proxy.</p>
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -464,7 +475,15 @@ this always falls back to the userspace proxy.
|
||||
|
||||
- [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration)
|
||||
|
||||
ClientConnectionConfiguration contains details for constructing a client.
|
||||
- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration)
|
||||
|
||||
- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta3-KubeSchedulerConfiguration)
|
||||
|
||||
- [GenericControllerManagerConfiguration](#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration)
|
||||
|
||||
|
||||
<p>ClientConnectionConfiguration contains details for constructing a client.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -475,37 +494,75 @@ ClientConnectionConfiguration contains details for constructing a client.
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
kubeconfig is the path to a KubeConfig file.
|
||||
<p>kubeconfig is the path to a KubeConfig file.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>acceptContentTypes</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
acceptContentTypes defines the Accept header sent by clients when connecting to a server, overriding the
|
||||
<p>acceptContentTypes defines the Accept header sent by clients when connecting to a server, overriding the
|
||||
default value of 'application/json'. This field will control all connections to the server used by a particular
|
||||
client.
|
||||
client.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>contentType</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
contentType is the content type used when sending data to the server from this client.
|
||||
<p>contentType is the content type used when sending data to the server from this client.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>qps</code> <B>[Required]</B><br/>
|
||||
<code>float32</code>
|
||||
</td>
|
||||
<td>
|
||||
qps controls the number of queries per second allowed for this connection.
|
||||
<p>qps controls the number of queries per second allowed for this connection.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>burst</code> <B>[Required]</B><br/>
|
||||
<code>int32</code>
|
||||
</td>
|
||||
<td>
|
||||
burst allows extra queries to accumulate when a client is exceeding its rate.
|
||||
<p>burst allows extra queries to accumulate when a client is exceeding its rate.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `DebuggingConfiguration` {#DebuggingConfiguration}
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration)
|
||||
|
||||
- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta3-KubeSchedulerConfiguration)
|
||||
|
||||
- [GenericControllerManagerConfiguration](#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration)
|
||||
|
||||
|
||||
<p>DebuggingConfiguration holds configuration for Debugging related features.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
<tr><td><code>enableProfiling</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
<p>enableProfiling enables profiling via web interface host:port/debug/pprof/</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>enableContentionProfiling</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
<p>enableContentionProfiling enables lock contention profiling, if
|
||||
enableProfiling is true.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -516,9 +573,11 @@ client.
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [LoggingConfiguration](#LoggingConfiguration)
|
||||
|
||||
|
||||
FormatOptions contains options for the different logging formats.
|
||||
<p>FormatOptions contains options for the different logging formats.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -529,7 +588,7 @@ FormatOptions contains options for the different logging formats.
|
||||
<a href="#JSONOptions"><code>JSONOptions</code></a>
|
||||
</td>
|
||||
<td>
|
||||
[Experimental] JSON contains options for logging format "json".
|
||||
<p>[Experimental] JSON contains options for logging format "json".</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -542,7 +601,9 @@ FormatOptions contains options for the different logging formats.
|
||||
|
||||
- [FormatOptions](#FormatOptions)
|
||||
|
||||
JSONOptions contains options for logging format "json".
|
||||
|
||||
<p>JSONOptions contains options for logging format "json".</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -553,17 +614,176 @@ JSONOptions contains options for logging format "json".
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
[Experimental] SplitStream redirects error messages to stderr while
|
||||
<p>[Experimental] SplitStream redirects error messages to stderr while
|
||||
info messages go to stdout, with buffering. The default is to write
|
||||
both to stdout, without buffering.
|
||||
both to stdout, without buffering.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>infoBufferSize</code> <B>[Required]</B><br/>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#QuantityValue"><code>k8s.io/apimachinery/pkg/api/resource.QuantityValue</code></a>
|
||||
</td>
|
||||
<td>
|
||||
[Experimental] InfoBufferSize sets the size of the info stream when
|
||||
using split streams. The default is zero, which disables buffering.
|
||||
<p>[Experimental] InfoBufferSize sets the size of the info stream when
|
||||
using split streams. The default is zero, which disables buffering.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `LeaderElectionConfiguration` {#LeaderElectionConfiguration}
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration)
|
||||
|
||||
- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta3-KubeSchedulerConfiguration)
|
||||
|
||||
- [GenericControllerManagerConfiguration](#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration)
|
||||
|
||||
|
||||
<p>LeaderElectionConfiguration defines the configuration of leader election
|
||||
clients for components that can run with leader election enabled.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
<tr><td><code>leaderElect</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
<p>leaderElect enables a leader election client to gain leadership
|
||||
before executing the main loop. Enable this when running replicated
|
||||
components for high availability.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>leaseDuration</code> <B>[Required]</B><br/>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<p>leaseDuration is the duration that non-leader candidates will wait
|
||||
after observing a leadership renewal until attempting to acquire
|
||||
leadership of a led but unrenewed leader slot. This is effectively the
|
||||
maximum duration that a leader can be stopped before it is replaced
|
||||
by another candidate. This is only applicable if leader election is
|
||||
enabled.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>renewDeadline</code> <B>[Required]</B><br/>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<p>renewDeadline is the interval between attempts by the acting master to
|
||||
renew a leadership slot before it stops leading. This must be less
|
||||
than or equal to the lease duration. This is only applicable if leader
|
||||
election is enabled.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>retryPeriod</code> <B>[Required]</B><br/>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<p>retryPeriod is the duration the clients should wait between attempting
|
||||
acquisition and renewal of a leadership. This is only applicable if
|
||||
leader election is enabled.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>resourceLock</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<p>resourceLock indicates the resource object type that will be used to lock
|
||||
during leader election cycles.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>resourceName</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<p>resourceName indicates the name of resource object that will be used to lock
|
||||
during leader election cycles.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>resourceNamespace</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<p>resourceName indicates the namespace of resource object that will be used to lock
|
||||
during leader election cycles.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `LoggingConfiguration` {#LoggingConfiguration}
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
|
||||
|
||||
<p>LoggingConfiguration contains logging options
|
||||
Refer <a href="https://github.com/kubernetes/component-base/blob/master/logs/options.go">Logs Options</a> for more information.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
<tr><td><code>format</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<p>Format Flag specifies the structure of log messages.
|
||||
default value of format is <code>text</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>flushFrequency</code> <B>[Required]</B><br/>
|
||||
<a href="https://pkg.go.dev/time#Duration"><code>time.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<p>Maximum number of seconds between log flushes. Ignored if the
|
||||
selected logging backend writes log messages without buffering.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>verbosity</code> <B>[Required]</B><br/>
|
||||
<code>uint32</code>
|
||||
</td>
|
||||
<td>
|
||||
<p>Verbosity is the threshold that determines which log messages are
|
||||
logged. Default is zero which logs only the most important
|
||||
messages. Higher values enable additional messages. Error messages
|
||||
are always logged.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>vmodule</code> <B>[Required]</B><br/>
|
||||
<a href="#VModuleConfiguration"><code>VModuleConfiguration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<p>VModule overrides the verbosity threshold for individual files.
|
||||
Only supported for "text" log format.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>sanitization</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
<p>[Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens).
|
||||
Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production.`)</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>options</code> <B>[Required]</B><br/>
|
||||
<a href="#FormatOptions"><code>FormatOptions</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<p>[Experimental] Options holds additional parameters that are specific
|
||||
to the different logging formats. Only the options for the selected
|
||||
format get used, but all of them get validated.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
@@ -572,11 +792,14 @@ using split streams. The default is zero, which disables buffering.
|
||||
## `VModuleConfiguration` {#VModuleConfiguration}
|
||||
|
||||
(Alias of `[]k8s.io/component-base/config/v1alpha1.VModuleItem`)
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [LoggingConfiguration](#LoggingConfiguration)
|
||||
|
||||
|
||||
VModuleConfiguration is a collection of individual file names or patterns
|
||||
and the corresponding verbosity threshold.
|
||||
<p>VModuleConfiguration is a collection of individual file names or patterns
|
||||
and the corresponding verbosity threshold.</p>
|
||||
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -13,102 +13,14 @@ auto_generated: true
|
||||
|
||||
|
||||
|
||||
## `FormatOptions` {#FormatOptions}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [LoggingConfiguration](#LoggingConfiguration)
|
||||
|
||||
|
||||
FormatOptions contains options for the different logging formats.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>json</code> <B>[Required]</B><br/>
|
||||
<a href="#JSONOptions"><code>JSONOptions</code></a>
|
||||
</td>
|
||||
<td>
|
||||
[Experimental] JSON contains options for logging format "json".</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `JSONOptions` {#JSONOptions}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [FormatOptions](#FormatOptions)
|
||||
|
||||
|
||||
JSONOptions contains options for logging format "json".
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>splitStream</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
[Experimental] SplitStream redirects error messages to stderr while
|
||||
info messages go to stdout, with buffering. The default is to write
|
||||
both to stdout, without buffering.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>infoBufferSize</code> <B>[Required]</B><br/>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#QuantityValue"><code>k8s.io/apimachinery/pkg/api/resource.QuantityValue</code></a>
|
||||
</td>
|
||||
<td>
|
||||
[Experimental] InfoBufferSize sets the size of the info stream when
|
||||
using split streams. The default is zero, which disables buffering.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `VModuleConfiguration` {#VModuleConfiguration}
|
||||
|
||||
(Alias of `[]k8s.io/component-base/config/v1alpha1.VModuleItem`)
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [LoggingConfiguration](#LoggingConfiguration)
|
||||
|
||||
|
||||
VModuleConfiguration is a collection of individual file names or patterns
|
||||
and the corresponding verbosity threshold.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## `CredentialProviderConfig` {#kubelet-config-k8s-io-v1alpha1-CredentialProviderConfig}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
CredentialProviderConfig is the configuration containing information about
|
||||
<p>CredentialProviderConfig is the configuration containing information about
|
||||
each exec credential provider. Kubelet reads this configuration from disk and enables
|
||||
each provider as specified by the CredentialProvider type.
|
||||
each provider as specified by the CredentialProvider type.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
@@ -117,165 +29,221 @@ each provider as specified by the CredentialProvider type.
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>kubelet.config.k8s.io/v1alpha1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>CredentialProviderConfig</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>providers</code> <B>[Required]</B><br/>
|
||||
<a href="#kubelet-config-k8s-io-v1alpha1-CredentialProvider"><code>[]CredentialProvider</code></a>
|
||||
</td>
|
||||
<td>
|
||||
providers is a list of credential provider plugins that will be enabled by the kubelet.
|
||||
<p>providers is a list of credential provider plugins that will be enabled by the kubelet.
|
||||
Multiple providers may match against a single image, in which case credentials
|
||||
from all providers will be returned to the kubelet. If multiple providers are called
|
||||
for a single image, the results are combined. If providers return overlapping
|
||||
auth keys, the value from the provider earlier in this list is used.</td>
|
||||
auth keys, the value from the provider earlier in this list is used.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `CredentialProvider` {#kubelet-config-k8s-io-v1alpha1-CredentialProvider}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [CredentialProviderConfig](#kubelet-config-k8s-io-v1alpha1-CredentialProviderConfig)
|
||||
|
||||
|
||||
CredentialProvider represents an exec plugin to be invoked by the kubelet. The plugin is only
|
||||
invoked when an image being pulled matches the images handled by the plugin (see matchImages).
|
||||
<p>CredentialProvider represents an exec plugin to be invoked by the kubelet. The plugin is only
|
||||
invoked when an image being pulled matches the images handled by the plugin (see matchImages).</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>
|
||||
name is the required name of the credential provider. It must match the name of the
|
||||
<p>name is the required name of the credential provider. It must match the name of the
|
||||
provider executable as seen by the kubelet. The executable must be in the kubelet's
|
||||
bin directory (set by the --image-credential-provider-bin-dir flag).</td>
|
||||
bin directory (set by the --image-credential-provider-bin-dir flag).</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>matchImages</code> <B>[Required]</B><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
matchImages is a required list of strings used to match against images in order to
|
||||
<p>matchImages is a required list of strings used to match against images in order to
|
||||
determine if this provider should be invoked. If one of the strings matches the
|
||||
requested image from the kubelet, the plugin will be invoked and given a chance
|
||||
to provide credentials. Images are expected to contain the registry domain
|
||||
and URL path.
|
||||
|
||||
Each entry in matchImages is a pattern which can optionally contain a port and a path.
|
||||
and URL path.</p>
|
||||
<p>Each entry in matchImages is a pattern which can optionally contain a port and a path.
|
||||
Globs can be used in the domain, but not in the port or the path. Globs are supported
|
||||
as subdomains like '∗.k8s.io' or 'k8s.∗.io', and top-level-domains such as 'k8s.∗'.
|
||||
Matching partial subdomains like 'app∗.k8s.io' is also supported. Each glob can only match
|
||||
a single subdomain segment, so ∗.io does not match ∗.k8s.io.
|
||||
|
||||
A match exists between an image and a matchImage when all of the below are true:
|
||||
- Both contain the same number of domain parts and each part matches.
|
||||
- The URL path of an imageMatch must be a prefix of the target image URL path.
|
||||
- If the imageMatch contains a port, then the port must match in the image as well.
|
||||
|
||||
Example values of matchImages:
|
||||
- 123456789.dkr.ecr.us-east-1.amazonaws.com
|
||||
- ∗.azurecr.io
|
||||
- gcr.io
|
||||
- ∗.∗.registry.io
|
||||
- registry.io:8080/path</td>
|
||||
as subdomains like '<em>.k8s.io' or 'k8s.</em>.io', and top-level-domains such as 'k8s.<em>'.
|
||||
Matching partial subdomains like 'app</em>.k8s.io' is also supported. Each glob can only match
|
||||
a single subdomain segment, so *.io does not match *.k8s.io.</p>
|
||||
<p>A match exists between an image and a matchImage when all of the below are true:</p>
|
||||
<ul>
|
||||
<li>Both contain the same number of domain parts and each part matches.</li>
|
||||
<li>The URL path of an imageMatch must be a prefix of the target image URL path.</li>
|
||||
<li>If the imageMatch contains a port, then the port must match in the image as well.</li>
|
||||
</ul>
|
||||
<p>Example values of matchImages:</p>
|
||||
<ul>
|
||||
<li>123456789.dkr.ecr.us-east-1.amazonaws.com</li>
|
||||
<li>*.azurecr.io</li>
|
||||
<li>gcr.io</li>
|
||||
<li><em>.</em>.registry.io</li>
|
||||
<li>registry.io:8080/path</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>defaultCacheDuration</code> <B>[Required]</B><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
defaultCacheDuration is the default duration the plugin will cache credentials in-memory
|
||||
if a cache duration is not provided in the plugin response. This field is required.</td>
|
||||
<p>defaultCacheDuration is the default duration the plugin will cache credentials in-memory
|
||||
if a cache duration is not provided in the plugin response. This field is required.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>apiVersion</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Required input version of the exec CredentialProviderRequest. The returned CredentialProviderResponse
|
||||
MUST use the same encoding version as the input. Current supported values are:
|
||||
- credentialprovider.kubelet.k8s.io/v1alpha1</td>
|
||||
<p>Required input version of the exec CredentialProviderRequest. The returned CredentialProviderResponse
|
||||
MUST use the same encoding version as the input. Current supported values are:</p>
|
||||
<ul>
|
||||
<li>credentialprovider.kubelet.k8s.io/v1alpha1</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>args</code><br/>
|
||||
<code>[]string</code>
|
||||
</td>
|
||||
<td>
|
||||
Arguments to pass to the command when executing it.</td>
|
||||
<p>Arguments to pass to the command when executing it.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>env</code><br/>
|
||||
<a href="#kubelet-config-k8s-io-v1alpha1-ExecEnvVar"><code>[]ExecEnvVar</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Env defines additional environment variables to expose to the process. These
|
||||
<p>Env defines additional environment variables to expose to the process. These
|
||||
are unioned with the host's environment, as well as variables client-go uses
|
||||
to pass argument to the plugin.</td>
|
||||
to pass argument to the plugin.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `ExecEnvVar` {#kubelet-config-k8s-io-v1alpha1-ExecEnvVar}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [CredentialProvider](#kubelet-config-k8s-io-v1alpha1-CredentialProvider)
|
||||
|
||||
|
||||
ExecEnvVar is used for setting environment variables when executing an exec-based
|
||||
credential plugin.
|
||||
<p>ExecEnvVar is used for setting environment variables when executing an exec-based
|
||||
credential plugin.</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>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>value</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<span class="text-muted">No description provided.</span>
|
||||
</td>
|
||||
<span class="text-muted">No description provided.</span></td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## `FormatOptions` {#FormatOptions}
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
|
||||
|
||||
<p>FormatOptions contains options for the different logging formats.</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
<tr><td><code>json</code> <B>[Required]</B><br/>
|
||||
<a href="#JSONOptions"><code>JSONOptions</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<p>[Experimental] JSON contains options for logging format "json".</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `JSONOptions` {#JSONOptions}
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [FormatOptions](#FormatOptions)
|
||||
|
||||
|
||||
<p>JSONOptions contains options for logging format "json".</p>
|
||||
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
<tr><td><code>splitStream</code> <B>[Required]</B><br/>
|
||||
<code>bool</code>
|
||||
</td>
|
||||
<td>
|
||||
<p>[Experimental] SplitStream redirects error messages to stderr while
|
||||
info messages go to stdout, with buffering. The default is to write
|
||||
both to stdout, without buffering.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>infoBufferSize</code> <B>[Required]</B><br/>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#QuantityValue"><code>k8s.io/apimachinery/pkg/api/resource.QuantityValue</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<p>[Experimental] InfoBufferSize sets the size of the info stream when
|
||||
using split streams. The default is zero, which disables buffering.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `VModuleConfiguration` {#VModuleConfiguration}
|
||||
|
||||
(Alias of `[]k8s.io/component-base/config/v1alpha1.VModuleItem`)
|
||||
|
||||
**Appears in:**
|
||||
|
||||
|
||||
|
||||
<p>VModuleConfiguration is a collection of individual file names or patterns
|
||||
and the corresponding verbosity threshold.</p>
|
||||
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,192 @@
|
||||
---
|
||||
title: Kubelet CredentialProvider (v1alpha1)
|
||||
content_type: tool-reference
|
||||
package: credentialprovider.kubelet.k8s.io/v1alpha1
|
||||
auto_generated: true
|
||||
---
|
||||
|
||||
|
||||
## Resource Types
|
||||
|
||||
|
||||
- [CredentialProviderRequest](#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderRequest)
|
||||
- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderResponse)
|
||||
|
||||
|
||||
|
||||
|
||||
## `CredentialProviderRequest` {#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderRequest}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
CredentialProviderRequest includes the image that the kubelet requires authentication for.
|
||||
Kubelet will pass this request object to the plugin via stdin. In general, plugins should
|
||||
prefer responding with the same apiVersion they were sent.
|
||||
|
||||
<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>credentialprovider.kubelet.k8s.io/v1alpha1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>CredentialProviderRequest</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>image</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
image is the container image that is being pulled as part of the
|
||||
credential provider plugin request. Plugins may optionally parse the image
|
||||
to extract any information required to fetch credentials.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `CredentialProviderResponse` {#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderResponse}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
CredentialProviderResponse holds credentials that the kubelet should use for the specified
|
||||
image provided in the original request. Kubelet will read the response from the plugin via stdout.
|
||||
This response should be set to the same apiVersion as CredentialProviderRequest.
|
||||
|
||||
<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>credentialprovider.kubelet.k8s.io/v1alpha1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>CredentialProviderResponse</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>cacheKeyType</code> <B>[Required]</B><br/>
|
||||
<a href="#credentialprovider-kubelet-k8s-io-v1alpha1-PluginCacheKeyType"><code>PluginCacheKeyType</code></a>
|
||||
</td>
|
||||
<td>
|
||||
cacheKeyType indiciates the type of caching key to use based on the image provided
|
||||
in the request. There are three valid values for the cache key type: Image, Registry, and
|
||||
Global. If an invalid value is specified, the response will NOT be used by the kubelet.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>cacheDuration</code><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
cacheDuration indicates the duration the provided credentials should be cached for.
|
||||
The kubelet will use this field to set the in-memory cache duration for credentials
|
||||
in the AuthConfig. If null, the kubelet will use defaultCacheDuration provided in
|
||||
CredentialProviderConfig. If set to 0, the kubelet will not cache the provided AuthConfig.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>auth</code><br/>
|
||||
<a href="#credentialprovider-kubelet-k8s-io-v1alpha1-AuthConfig"><code>map[string]k8s.io/kubelet/pkg/apis/credentialprovider/v1alpha1.AuthConfig</code></a>
|
||||
</td>
|
||||
<td>
|
||||
auth is a map containing authentication information passed into the kubelet.
|
||||
Each key is a match image string (more on this below). The corresponding authConfig value
|
||||
should be valid for all images that match against this key. A plugin should set
|
||||
this field to null if no valid credentials can be returned for the requested image.
|
||||
|
||||
Each key in the map is a pattern which can optionally contain a port and a path.
|
||||
Globs can be used in the domain, but not in the port or the path. Globs are supported
|
||||
as subdomains like '∗.k8s.io' or 'k8s.∗.io', and top-level-domains such as 'k8s.∗'.
|
||||
Matching partial subdomains like 'app∗.k8s.io' is also supported. Each glob can only match
|
||||
a single subdomain segment, so ∗.io does not match ∗.k8s.io.
|
||||
|
||||
The kubelet will match images against the key when all of the below are true:
|
||||
- Both contain the same number of domain parts and each part matches.
|
||||
- The URL path of an imageMatch must be a prefix of the target image URL path.
|
||||
- If the imageMatch contains a port, then the port must match in the image as well.
|
||||
|
||||
When multiple keys are returned, the kubelet will traverse all keys in reverse order so that:
|
||||
- longer keys come before shorter keys with the same prefix
|
||||
- non-wildcard keys come before wildcard keys with the same prefix.
|
||||
|
||||
For any given match, the kubelet will attempt an image pull with the provided credentials,
|
||||
stopping after the first successfully authenticated pull.
|
||||
|
||||
Example keys:
|
||||
- 123456789.dkr.ecr.us-east-1.amazonaws.com
|
||||
- ∗.azurecr.io
|
||||
- gcr.io
|
||||
- ∗.∗.registry.io
|
||||
- registry.io:8080/path</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `AuthConfig` {#credentialprovider-kubelet-k8s-io-v1alpha1-AuthConfig}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderResponse)
|
||||
|
||||
|
||||
AuthConfig contains authentication information for a container registry.
|
||||
Only username/password based authentication is supported today, but more authentication
|
||||
mechanisms may be added in the future.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>username</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
username is the username used for authenticating to the container registry
|
||||
An empty username is valid.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>password</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
password is the password used for authenticating to the container registry
|
||||
An empty password is valid.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `PluginCacheKeyType` {#credentialprovider-kubelet-k8s-io-v1alpha1-PluginCacheKeyType}
|
||||
|
||||
(Alias of `string`)
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderResponse)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -73,6 +73,10 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \
|
||||
&& kubectl config use-context gce
|
||||
|
||||
kubectl config unset users.foo # delete user foo
|
||||
|
||||
# short alias to set/show context/namespace (only works for bash and bash-compatible shells, current context to be set before using kn to set namespace)
|
||||
alias kx='f() { [ "$1" ] && kubectl config use-context $1 || kubectl config current-context ; } ; f'
|
||||
alias kn='f() { [ "$1" ] && kubectl config set-context --current --namespace $1 || kubectl config view --minify | grep namespace | cut -d" " -f6 ; } ; f'
|
||||
```
|
||||
|
||||
## Kubectl apply
|
||||
@@ -212,10 +216,10 @@ kubectl diff -f ./my-manifest.yaml
|
||||
|
||||
# Produce a period-delimited tree of all keys returned for nodes
|
||||
# Helpful when locating a key within a complex nested JSON structure
|
||||
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
|
||||
kubectl get nodes -o json | jq -c 'paths|join(".")'
|
||||
|
||||
# Produce a period-delimited tree of all keys returned for pods, etc
|
||||
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
|
||||
kubectl get pods -o json | jq -c 'paths|join(".")'
|
||||
|
||||
# Produce ENV for all pods, assuming you have a default container for the pods, default namespace and the `env` command is supported.
|
||||
# Helpful when running any supported command across all pods, not just `env`
|
||||
|
||||
@@ -80,6 +80,14 @@ Used on: All Objects
|
||||
|
||||
This annotation is used for describing specific behaviour of given object.
|
||||
|
||||
### kubernetes.io/enforce-mountable-secrets {#enforce-mountable-secrets}
|
||||
|
||||
Example: `kubernetes.io/enforce-mountable-secrets: "true"`
|
||||
|
||||
Used on: ServiceAccount
|
||||
|
||||
The value for this annotation must be **true** to take effect. This annotation indicates that pods running as this service account may only reference Secret API objects specified in the service account's `secrets` field.
|
||||
|
||||
### controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost}
|
||||
|
||||
Example: `controller.kubernetes.io/pod-deletion-cost=10`
|
||||
|
||||
@@ -183,7 +183,7 @@ and starting the **watch** from the `resourceVersion` that was returned.
|
||||
|
||||
For subscribing to collections, Kubernetes client libraries typically offer some form
|
||||
of standard tool for this **list**-then-**watch** logic. (In the Go client library,
|
||||
this is called a `Reflector` and is located in the `k8s.io/client-go/cache` package.)
|
||||
this is called a `Reflector` and is located in the `k8s.io/client-go/tools/cache` package.)
|
||||
|
||||
### Watch bookmarks
|
||||
|
||||
|
||||
@@ -70,6 +70,8 @@ few different ways:
|
||||
Other alternatives for enforcing security profiles are being developed in the Kubernetes
|
||||
ecosystem:
|
||||
|
||||
- [Kubewarden](https://github.com/kubewarden).
|
||||
- [Kyverno](https://kyverno.io/policies/).
|
||||
- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper).
|
||||
|
||||
The decision to go with a _built-in_ solution (e.g. PodSecurity admission controller) versus a
|
||||
|
||||
@@ -225,6 +225,10 @@ sudo systemctl enable --now kubelet
|
||||
|
||||
- You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm.
|
||||
|
||||
- If the `baseurl` fails because your Red Hat-based distribution cannot interpret `basearch`, replace `\$basearch` with your computer's architecture.
|
||||
Type `uname -m` to see that value.
|
||||
For example, the `baseurl` URL for `x86_64` could be: `https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Without a package manager" %}}
|
||||
Install CNI plugins (required for most pod network):
|
||||
|
||||
@@ -86,12 +86,36 @@ The output is similar to this:
|
||||
|
||||
### Without kubectl proxy
|
||||
|
||||
Use `kubectl describe secret...` to get the token for the default service account with grep/cut:
|
||||
Use `kubectl apply` and `kubectl describe secret...` to create a token for the default service account with grep/cut:
|
||||
|
||||
First, create the Secret, requesting a token for the default ServiceAccount:
|
||||
|
||||
```shell
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: default-token
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: default
|
||||
type: kubernetes.io/service-account-token
|
||||
EOF
|
||||
```
|
||||
|
||||
Next, wait for the token controller to populate the Secret with a token:
|
||||
|
||||
```shell
|
||||
while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
|
||||
echo "waiting for token..." >&2
|
||||
sleep 1
|
||||
done
|
||||
```
|
||||
|
||||
Capture and use the generated token:
|
||||
|
||||
```shell
|
||||
APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
|
||||
SECRET_NAME=$(kubectl get secrets | grep ^default | cut -f1 -d ' ')
|
||||
TOKEN=$(kubectl describe secret $SECRET_NAME | grep -E '^token' | cut -f2 -d':' | tr -d " ")
|
||||
TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")
|
||||
|
||||
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
```
|
||||
@@ -117,8 +141,7 @@ Using `jsonpath`:
|
||||
|
||||
```shell
|
||||
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
SECRET_NAME=$(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}')
|
||||
TOKEN=$(kubectl get secret $SECRET_NAME -o jsonpath='{.data.token}' | base64 --decode)
|
||||
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
|
||||
|
||||
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
```
|
||||
|
||||
@@ -95,8 +95,25 @@ export CLUSTER_NAME="some_server_name"
|
||||
# Point to the API server referring the cluster name
|
||||
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
|
||||
|
||||
# Gets the token value
|
||||
TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)
|
||||
# Create a secret to hold a token for the default service account
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: default-token
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: default
|
||||
type: kubernetes.io/service-account-token
|
||||
EOF
|
||||
|
||||
# Wait for the token controller to populate the secret with a token:
|
||||
while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
|
||||
echo "waiting for token..." >&2
|
||||
sleep 1
|
||||
done
|
||||
|
||||
# Get the token value
|
||||
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
|
||||
|
||||
# Explore the API with TOKEN
|
||||
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
@@ -119,26 +136,6 @@ The output is similar to this:
|
||||
}
|
||||
```
|
||||
|
||||
Using `jsonpath` approach:
|
||||
|
||||
```shell
|
||||
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
|
||||
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The above example uses the `--insecure` flag. This leaves it subject to MITM
|
||||
attacks. When kubectl accesses the cluster it uses a stored root certificate
|
||||
and client certificates to access the server. (These are installed in the
|
||||
|
||||
@@ -361,3 +361,12 @@ We also recommend restarting any components (e.g. `kube-scheduler`,
|
||||
stale data. Note that in practice, the restore takes a bit of time. During the
|
||||
restoration, critical components will lose leader lock and restart themselves.
|
||||
{{< /note >}}
|
||||
|
||||
## Upgrading etcd clusters
|
||||
|
||||
|
||||
For more details on etcd upgrade, please refer to the [etcd upgrades](https://etcd.io/docs/latest/upgrades/) documentation.
|
||||
|
||||
{{< note >}}
|
||||
Before you start an upgrade, please back up your etcd cluster first.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -46,7 +46,8 @@ management policies to determine some placement preferences on the node.
|
||||
### Configuration
|
||||
|
||||
The CPU Manager policy is set with the `--cpu-manager-policy` kubelet
|
||||
option. There are two supported policies:
|
||||
flag or the `cpuManagerPolicy` field in [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/).
|
||||
There are two supported policies:
|
||||
|
||||
* [`none`](#none-policy): the default policy.
|
||||
* [`static`](#static-policy): allows pods with certain resource characteristics to be
|
||||
@@ -68,6 +69,27 @@ and `CPUManagerPolicyBetaOptions` feature gates. Diverging from the Kubernetes s
|
||||
feature gates guard groups of options, because it would have been too cumbersome to add a feature
|
||||
gate for each individual option.
|
||||
|
||||
### Changing the CPU Manager Policy
|
||||
|
||||
Since the CPU manger policy can only be applied when kubelet spawns new pods, simply changing from
|
||||
"none" to "static" won't apply to existing pods. So in order to properly change the CPU manager
|
||||
policy on a node, perform the following steps:
|
||||
|
||||
1. [Drain](/docs/tasks/administer-cluster/safely-drain-node) the node.
|
||||
2. Stop kubelet.
|
||||
3. Remove the old CPU manager state file. The path to this file is
|
||||
`/var/lib/kubelet/cpu_manager_state` by default. This clears the state maintained by the
|
||||
CPUManager so that the cpu-sets set up by the new policy won’t conflict with it.
|
||||
4. Edit the kubelet configuration to change the CPU manager policy to the desired value.
|
||||
5. Start kubelet.
|
||||
|
||||
Repeat this process for every node that needs its CPU manager policy changed. Skipping this
|
||||
process will result in kubelet crashlooping with the following error:
|
||||
|
||||
```
|
||||
could not restore state from checkpoint: configured policy "static" differs from state checkpoint policy "none", please drain this node and delete the CPU manager checkpoint file "/var/lib/kubelet/cpu_manager_state" before restarting Kubelet
|
||||
```
|
||||
|
||||
### None policy
|
||||
|
||||
The `none` policy explicitly enables the existing default CPU
|
||||
|
||||
+1
-1
@@ -170,7 +170,7 @@ kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.ya
|
||||
```
|
||||
|
||||
The output shows that the Pod does not get created, because it defines an unacceptable container.
|
||||
That container is not acceptable because it specifies a CPU limit that is lower than the
|
||||
That container is not acceptable because it specifies a CPU request that is lower than the
|
||||
enforced minimum:
|
||||
|
||||
```
|
||||
|
||||
+1
-1
@@ -177,7 +177,7 @@ Here are two of the restrictions that a resource quota imposes on a namespace:
|
||||
* For every Pod that runs in the namespace, the Pod and each of its containers must have a memory limit.
|
||||
(If you specify a memory limit for every container in a Pod, Kubernetes can infer the Pod-level memory
|
||||
limit by adding up the limits for its containers).
|
||||
* CPU limits apply a resource reservation on the node where the Pod in question is scheduled.
|
||||
* Memory limits apply a resource reservation on the node where the Pod in question is scheduled.
|
||||
The total amount of memory reserved for all Pods in the namespace must not exceed a specified limit.
|
||||
* The total amount of memory actually used by all Pods in the namespace must also not exceed a specified limit.
|
||||
|
||||
|
||||
@@ -130,6 +130,12 @@ The output is similar to:
|
||||
Now you can decode the `password` data:
|
||||
|
||||
```shell
|
||||
# This is an example for documentation purposes.
|
||||
# If you did things this way, the data 'MWYyZDFlMmU2N2Rm' could be stored in
|
||||
# your shell history.
|
||||
# Someone with access to you computer could find that remembered command
|
||||
# and base-64 decode the secret, perhaps without your knowledge.
|
||||
# It's usually better to combine the steps, as shown later in the page.
|
||||
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
|
||||
```
|
||||
|
||||
@@ -139,6 +145,15 @@ The output is similar to:
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
In order to avoid storing a secret encoded value in your shell history, you can
|
||||
run the following command:
|
||||
|
||||
```shell
|
||||
kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode
|
||||
```
|
||||
|
||||
The output shall be similar as above.
|
||||
|
||||
## Clean Up
|
||||
|
||||
Delete the Secret you created:
|
||||
|
||||
@@ -199,7 +199,7 @@ As Pod specs with GMSA fields populated (as described above) are applied in a cl
|
||||
|
||||
1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity.
|
||||
|
||||
## Authenticating to network shares usinig hostname of FQDN
|
||||
## Authenticating to network shares using hostname or FQDN
|
||||
|
||||
If you are experiencing issues connecting to SMB shares from Pods using hostname or FQDN, but are able to access the shares via their IPv4 address then make sure the following registry key is set on the Windows nodes.
|
||||
|
||||
@@ -225,7 +225,7 @@ kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
|
||||
|
||||
`nltest.exe /parentdomain` results in the following error:
|
||||
|
||||
```PowerShell
|
||||
```output
|
||||
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
|
||||
```
|
||||
|
||||
@@ -245,7 +245,7 @@ nltest.exe /query
|
||||
|
||||
Results in the following output:
|
||||
|
||||
```PowerShell
|
||||
```output
|
||||
I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
|
||||
```
|
||||
|
||||
@@ -257,7 +257,7 @@ nltest /sc_reset:domain.example
|
||||
|
||||
If the command is successful you will see and output similar to this:
|
||||
|
||||
```PowerShell
|
||||
```output
|
||||
Flags: 30 HAS_IP HAS_TIMESERV
|
||||
Trusted DC Name \\dc10.domain.example
|
||||
Trusted DC Connection Status Status = 0 0x0 NERR_Success
|
||||
|
||||
@@ -291,7 +291,7 @@ command line arguments to `kube-apiserver`:
|
||||
|
||||
* `--service-account-issuer`
|
||||
|
||||
It can be used as the Identifier of the service account token issuer. You can specify the `--service-account-issuer` argument multiple times, this can be useful to enable a non-disruptive change of the issuer. When this flag is specified multiple times, the first is used to generate tokens and all are used to determine which issuers are accepted. You must be running running Kubernetes v1.22 or later to be able to specify `--service-account-issuer` multiple times.
|
||||
It can be used as the Identifier of the service account token issuer. You can specify the `--service-account-issuer` argument multiple times, this can be useful to enable a non-disruptive change of the issuer. When this flag is specified multiple times, the first is used to generate tokens and all are used to determine which issuers are accepted. You must be running Kubernetes v1.22 or later to be able to specify `--service-account-issuer` multiple times.
|
||||
* `--service-account-key-file`
|
||||
|
||||
File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If specified multiple times, tokens signed by any of the specified keys are considered valid by the Kubernetes API server.
|
||||
|
||||
@@ -19,30 +19,323 @@ admission controller. This can be done effectively using a combination of dry-ru
|
||||
|
||||
- Ensure the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) is enabled.
|
||||
|
||||
This page assumes you are already familiar with the basic [Pod Security Admission](/docs/concepts/security/pod-security-admission/)
|
||||
concepts.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Steps
|
||||
## Overall approach
|
||||
|
||||
- **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.
|
||||
- **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.
|
||||
- **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.
|
||||
There are multiple strategies you can take for migrating from PodSecurityPolicy to Pod Security
|
||||
Admission. The following steps are one possible migration path, with a goal of minimizing both the
|
||||
risks of a production outage and of a security gap.
|
||||
|
||||
<!-- Keep section header numbering in sync with this list. -->
|
||||
0. Decide whether Pod Security Admission is the right fit for your use case.
|
||||
1. Review namespace permissions
|
||||
2. Simplify & standardize PodSecurityPolicies
|
||||
3. Update namespaces
|
||||
1. Identify an appropriate Pod Security level
|
||||
2. Verify the Pod Security level
|
||||
3. Enforce the Pod Security level
|
||||
4. Bypass PodSecurityPolicy
|
||||
4. Review namespace creation processes
|
||||
5. Disable PodSecurityPolicy
|
||||
|
||||
## 0. Decide whether Pod Security Admission is right for you {#is-psa-right-for-you}
|
||||
|
||||
Pod Security Admission was designed to meet the most common security needs out of the box, and to
|
||||
provide a standard set of security levels across clusters. However, it is less flexible than
|
||||
PodSecurityPolicy. Notably, the following features are supported by PodSecurityPolicy but not Pod
|
||||
Security Admission:
|
||||
|
||||
- **Setting default security constraints** - Pod Security Admission is a non-mutating admission
|
||||
controller, meaning it won't modify pods before validating them. If you were relying on this
|
||||
aspect of PSP, you will need to either modify your workloads to meet the Pod Security constraints,
|
||||
or use a [Mutating Admission Webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
to make those changes. See [Simplify & Standardize PodSecurityPolicies](#simplify-psps) below for more detail.
|
||||
- **Fine-grained control over policy definition** - Pod Security Admission only supports
|
||||
[3 standard levels](/docs/concepts/security/pod-security-standards/).
|
||||
If you require more control over specific constraints, then you will need to use a
|
||||
[Validating Admission Webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
to enforce those policies.
|
||||
- **Sub-namespace policy granularity** - PodSecurityPolicy lets you bind different policies to
|
||||
different Service Accounts or users, even within a single namespace. This approach has many
|
||||
pitfalls and is not recommended, but if you require this feature anyway you will
|
||||
need to use a 3rd party webhook instead. The exception to this is if you only need to completely exempt
|
||||
specific users or [RuntimeClasses](/docs/concepts/containers/runtime-class/), in which case Pod
|
||||
Security Admission does expose some
|
||||
[static configuration for exemptions](/docs/concepts/security/pod-security-admission/#exemptions).
|
||||
|
||||
Even if Pod Security Admission does not meet all of your needs it was designed to be _complementary_
|
||||
to other policy enforcement mechanisms, and can provide a useful fallback running alongside other
|
||||
admission webhooks.
|
||||
|
||||
|
||||
## 1. Review namespace permissions {#review-namespace-permissions}
|
||||
|
||||
Pod Security Admission is controlled by [labels on
|
||||
namespaces](/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces).
|
||||
This means that anyone who can update (or patch or create) a namespace can also modify the Pod
|
||||
Security level for that namespace, which could be used to bypass a more restrictive policy. Before
|
||||
proceeding, ensure that only trusted, privileged users have these namespace permissions. It is not
|
||||
recommended to grant these powerful permissions to users that shouldn't have elevated permissions,
|
||||
but if you must you will need to use an
|
||||
[admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
to place additional restrictions on setting Pod Security labels on Namespace objects.
|
||||
|
||||
## 2. Simplify & standardize PodSecurityPolicies {#simplify-psps}
|
||||
|
||||
In this section, you will reduce mutating PodSecurityPolicies and remove options that are outside
|
||||
the scope of the Pod Security Standards. You should make the changes recommended here to an offline
|
||||
copy of the original PodSecurityPolicy being modified. The cloned PSP should have a different
|
||||
name that is alphabetically before the original (for example, prepend a `0` to it). Do not create the
|
||||
new policies in Kubernetes yet - that will be covered in the [Rollout the updated
|
||||
policies](#psp-update-rollout) section below.
|
||||
|
||||
### 2.a. Eliminate purely mutating fields {#eliminate-mutating-fields}
|
||||
|
||||
If a PodSecurityPolicy is mutating pods, then you could end up with pods that don't meet the Pod
|
||||
Security level requirements when you finally turn PodSecurityPolicy off. In order to avoid this, you
|
||||
should eliminate all PSP mutation prior to switching over. Unfortunately PSP does not cleanly
|
||||
separate mutating & validating fields, so this is not a straightforward migration.
|
||||
|
||||
You can start by eliminating the fields that are purely mutating, and don't have any bearing on the
|
||||
validating policy. These fields (also listed in the
|
||||
[Mapping PodSecurityPolicies to Pod Security Standards](/docs/reference/access-authn-authz/psp-to-pod-security-standards/)
|
||||
reference) are:
|
||||
|
||||
- `.spec.defaultAllowPrivilegeEscalation`
|
||||
- `.spec.runtimeClass.defaultRuntimeClassName`
|
||||
- `.metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName']`
|
||||
- `.metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName']`
|
||||
- `.spec.defaultAddCapabilities` - Although technically a mutating & validating field, these should
|
||||
be merged into `.spec.allowedCapabilities` which performs the same validation without mutation.
|
||||
|
||||
{{< caution >}}
|
||||
Removing these could result in workloads missing required configuration, and cause problems. See
|
||||
[Rollout the updated policies](#psp-update-rollout) below for advice on how to roll these changes
|
||||
out safely.
|
||||
{{< /caution >}}
|
||||
|
||||
### 2.b. Eliminate options not covered by the Pod Security Standards {#eliminate-non-standard-options}
|
||||
|
||||
There are several fields in PodSecurityPolicy that are not covered by the Pod Security Standards. If
|
||||
you must enforce these options, you will need to supplement Pod Security Admission with an
|
||||
[admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/),
|
||||
which is outside the scope of this guide.
|
||||
|
||||
First, you can remove the purely validating fields that the Pod Security Standards do not cover.
|
||||
These fields (also listed in the
|
||||
[Mapping PodSecurityPolicies to Pod Security Standards](/docs/reference/access-authn-authz/psp-to-pod-security-standards/)
|
||||
reference with "no opinion") are:
|
||||
|
||||
- `.spec.allowedHostPaths`
|
||||
- `.spec.allowedFlexVolumes`
|
||||
- `.spec.allowedCSIDrivers`
|
||||
- `.spec.forbiddenSysctls`
|
||||
- `.spec.runtimeClass`
|
||||
|
||||
You can also remove the following fields, that are related to POSIX / UNIX group controls.
|
||||
|
||||
{{< caution >}}
|
||||
If any of these use the `MustRunAs` strategy they may be mutating! Removing these could result in
|
||||
workloads not setting the required groups, and cause problems. See
|
||||
[Rollout the updated policies](#psp-update-rollout) below for advice on how to roll these changes
|
||||
out safely.
|
||||
{{< /caution >}}
|
||||
|
||||
- `.spec.runAsGroup`
|
||||
- `.spec.supplementalGroups`
|
||||
- `.spec.fsGroup`
|
||||
|
||||
The remaining mutating fields are required to properly support the Pod Security Standards, and will
|
||||
need to be handled on a case-by-case basis later:
|
||||
|
||||
- `.spec.requiredDropCapabilities` - Required to drop `ALL` for the Restricted profile.
|
||||
- `.spec.seLinux` - (Only mutating with the `MustRunAs` rule) required to enforce the SELinux
|
||||
requirements of the Baseline & Restricted profiles.
|
||||
- `.spec.runAsUser` - (Non-mutating with the `RunAsAny` rule) required to enforce `RunAsNonRoot` for
|
||||
the Restricted profile.
|
||||
- `.spec.allowPrivilegeEscalation` - (Only mutating if set to `false`) required for the Restricted
|
||||
profile.
|
||||
|
||||
### 2.c. Rollout the updated PSPs {#psp-update-rollout}
|
||||
|
||||
Next, you can rollout the updated policies to your cluster. You should proceed with caution, as
|
||||
removing the mutating options may result in workloads missing required configuration.
|
||||
|
||||
For each updated PodSecurityPolicy:
|
||||
|
||||
1. Identify pods running under the original PSP. This can be done using the `kubernetes.io/psp`
|
||||
annotation. For example, using kubectl:
|
||||
```sh
|
||||
PSP_NAME="original" # Set the name of the PSP you're checking for
|
||||
kubectl get pods --all-namespaces -o jsonpath="{range .items[?(@.metadata.annotations.kubernetes\.io\/psp=='$PSP_NAME')]}{.metadata.namespace} {.metadata.name}{'\n'}{end}"
|
||||
```
|
||||
2. Compare these running pods against the original pod spec to determine whether PodSecurityPolicy
|
||||
has modified the pod. For pods created by a [workload resource](/docs/concepts/workloads/controllers/)
|
||||
you can compare the pod with the PodTemplate in the controller resource. If any changes are
|
||||
identified, the original Pod or PodTemplate should be updated with the desired configuration.
|
||||
The fields to review are:
|
||||
- `.metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']` (replace * with each container name)
|
||||
- `.spec.runtimeClassName`
|
||||
- `.spec.securityContext.fsGroup`
|
||||
- `.spec.securityContext.seccompProfile`
|
||||
- `.spec.securityContext.seLinuxOptions`
|
||||
- `.spec.securityContext.supplementalGroups`
|
||||
- On containers, under `.spec.containers[*]` and `.spec.initContainers[*]`:
|
||||
- `.securityContext.allowPrivilegeEscalation`
|
||||
- `.securityContext.capabilities.add`
|
||||
- `.securityContext.capabilities.drop`
|
||||
- `.securityContext.readOnlyRootFilesystem`
|
||||
- `.securityContext.runAsGroup`
|
||||
- `.securityContext.runAsNonRoot`
|
||||
- `.securityContext.runAsUser`
|
||||
- `.securityContext.seccompProfile`
|
||||
- `.securityContext.seLinuxOptions`
|
||||
3. Create the new PodSecurityPolicies. If any Roles or ClusterRoles are granting `use` on all PSPs
|
||||
this could cause the new PSPs to be used instead of their mutating counter-parts.
|
||||
4. Update your authorization to grant access to the new PSPs. In RBAC this means updating any Roles
|
||||
or ClusterRoles that grant the `use` permision on the original PSP to also grant it to the
|
||||
updated PSP.
|
||||
5. Verify: after some soak time, rerun the command from step 1 to see if any pods are still using
|
||||
the original PSPs. Note that pods need to be recreated after the new policies have been rolled
|
||||
out before they can be fully verified.
|
||||
6. (optional) Once you have verified that the original PSPs are no longer in use, you can delete
|
||||
them.
|
||||
|
||||
## 3. Update Namespaces {#update-namespaces}
|
||||
|
||||
The following steps will need to be performed on every namespace in the cluster. Commands referenced
|
||||
in these steps use the `$NAMESPACE` variable to refer to the namespace being updated.
|
||||
|
||||
### 3.a. Identify an appropriate Pod Security level {#identify-appropriate-level}
|
||||
|
||||
Start reviewing the [Pod Security Standards](/docs/concepts/security/pod-security-standards/) and
|
||||
familiarizing yourself with the 3 different levels.
|
||||
|
||||
There are several ways to choose a Pod Security level for your namespace:
|
||||
|
||||
1. **By security requirements for the namespace** - If you are familiar with the expected access
|
||||
level for the namespace, you can choose an appropriate level based on those requirements, similar
|
||||
to how one might approach this on a new cluster.
|
||||
2. **By existing PodSecurityPolicies** - Using the
|
||||
[Mapping PodSecurityPolicies to Pod Security Standards](/docs/reference/access-authn-authz/psp-to-pod-security-standards/)
|
||||
reference you can map each
|
||||
PSP to a Pod Security Standard level. If your PSPs aren't based on the Pod Security Standards, you
|
||||
may need to decide between choosing a level that is at least as permissive as the PSP, and a
|
||||
level that is at least as restrictive. You can see which PSPs are in use for pods in a given
|
||||
namespace with this command:
|
||||
```sh
|
||||
kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u
|
||||
```
|
||||
3. **By existing pods** - Using the strategies under [Verify the Pod Security level](#verify-pss-level),
|
||||
you can test out both the Baseline and Restricted levels to see
|
||||
whether they are sufficiently permissive for existing workloads, and chose the least-privileged
|
||||
valid level.
|
||||
|
||||
{{< caution >}}
|
||||
Options 2 & 3 above are based on _existing_ pods, and may miss workloads that aren't currently
|
||||
running, such as CronJobs, scale-to-zero workloads, or other workloads that haven't rolled out.
|
||||
{{< /caution >}}
|
||||
|
||||
### 3.b. Verify the Pod Security level {#verify-pss-level}
|
||||
|
||||
Once you have selected a Pod Security level for the namespace (or if you're trying several), it's a
|
||||
good idea to test it out first (you can skip this step if using the Privileged level). Pod Security
|
||||
includes several tools to help test and safely roll out profiles.
|
||||
|
||||
First, you can dry-run the policy, which will evaluate pods currently running in the namespace
|
||||
against the applied policy, without making the new policy take effect:
|
||||
```sh
|
||||
# $LEVEL is the level to dry-run, either "baseline" or "restricted".
|
||||
kubectl label --dry-run=server --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL
|
||||
```
|
||||
This command will return a warning for any _existing_ pods that are not valid under the proposed
|
||||
level.
|
||||
|
||||
The second option is better for catching workloads that are not currently running: audit mode. When
|
||||
running under audit-mode (as opposed to enforcing), pods that violate the policy level are recorded
|
||||
in the audit logs, which can be reviewed later after some soak time, but are not forbidden. Warning
|
||||
mode works similarly, but returns the warning to the user immediately. You can set the audit level
|
||||
on a namespace with this command:
|
||||
```sh
|
||||
kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL
|
||||
```
|
||||
|
||||
If either of these approaches yield unexpected violations, you will need to either update the
|
||||
violating workloads to meet the policy requirements, or relax the namespace Pod Security level.
|
||||
|
||||
### 3.c. Enforce the Pod Security level {#enforce-pod-security-level}
|
||||
|
||||
When you are satisfied that the chosen level can safely be enforced on the namespace, you can update
|
||||
the namespace to enforce the desired level:
|
||||
|
||||
```sh
|
||||
kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL
|
||||
```
|
||||
|
||||
### 3.d. Bypass PodSecurityPolicy {#bypass-psp}
|
||||
|
||||
Finally, you can effectively bypass PodSecurityPolicy at the namespace level by binding the fully
|
||||
{{< example file="policy/privileged-psp.yaml" >}}privileged PSP{{< /example >}} to all service
|
||||
accounts in the namespace.
|
||||
|
||||
```sh
|
||||
# The following cluster-scoped commands are only needed once.
|
||||
kubectl apply -f privileged-psp.yaml
|
||||
kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged
|
||||
|
||||
# Per-namespace disable
|
||||
kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE
|
||||
```
|
||||
|
||||
Since the privileged PSP is non-mutating, and the PSP admission controller always
|
||||
prefers non-mutating PSPs, this will ensure that pods in this namespace are no longer being modified
|
||||
or restricted by PodSecurityPolicy.
|
||||
|
||||
The advantage to disabling PodSecurityPolicy on a per-namespace basis like this is if a problem
|
||||
arises you can easily roll the change back by deleting the RoleBinding. Just make sure the
|
||||
pre-existing PodSecurityPolicies are still in place!
|
||||
|
||||
```sh
|
||||
# Undo PodSecurityPolicy disablement.
|
||||
kubectl delete -n $NAMESPACE rolebinding disable-psp
|
||||
```
|
||||
|
||||
## 4. Review namespace creation processes {#review-namespace-creation-process}
|
||||
|
||||
Now that existing namespaces have been updated to enforce Pod Security Admission, you should ensure
|
||||
that your processes and/or policies for creating new namespaces are updated to ensure that an
|
||||
appropriate Pod Security profile is applied to new namespaces.
|
||||
|
||||
You can also statically configure the Pod Security admission controller to set a default enforce,
|
||||
audit, and/or warn level for unlabeled namespaces. See
|
||||
[Configure the Admission Controller](docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
|
||||
for more information.
|
||||
|
||||
## 5. Disable PodSecurityPolicy {#disable-psp}
|
||||
|
||||
Finally, you're ready to disable PodSecurityPolicy. To do so, you will need to modify the admission
|
||||
configuration of the API server:
|
||||
[How do I turn off an admission controller?](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-off-an-admission-controller).
|
||||
|
||||
To verify that the PodSecurityPolicy admission controller is no longer enabled, you can manually run
|
||||
a test by impersonating a user without access to any PodSecurityPolicies (see the
|
||||
[PodSecurityPolicy example](/docs/concepts/policy/pod-security-policy/#example)), or by verifying in
|
||||
the API server logs. At startup, the API server outputs log lines listing the loaded admission
|
||||
controller plugins:
|
||||
|
||||
```
|
||||
I0218 00:59:44.903329 13 plugins.go:158] Loaded 16 mutating admission controller(s) successfully in the following order: NamespaceLifecycle,LimitRanger,ServiceAccount,NodeRestriction,TaintNodesByCondition,Priority,DefaultTolerationSeconds,ExtendedResourceToleration,PersistentVolumeLabel,DefaultStorageClass,StorageObjectInUseProtection,RuntimeClass,DefaultIngressClass,MutatingAdmissionWebhook.
|
||||
I0218 00:59:44.903350 13 plugins.go:161] Loaded 14 validating admission controller(s) successfully in the following order: LimitRanger,ServiceAccount,PodSecurity,Priority,PersistentVolumeClaimResize,RuntimeClass,CertificateApproval,CertificateSigning,CertificateSubjectRestriction,DenyServiceExternalIPs,ValidatingAdmissionWebhook,ResourceQuota.
|
||||
```
|
||||
|
||||
You should see `PodSecurity` (in the validating admission controllers), and neither list should
|
||||
contain `PodSecurityPolicy`.
|
||||
|
||||
Once you are certain the PSP admission controller is disabled (and after sufficient soak time to be
|
||||
confident you won't need to roll back), you are free to delete your PodSecurityPolicies and any
|
||||
associated Roles, ClusterRoles, RoleBindings and ClusterRoleBindings (just make sure they don't
|
||||
grant any other unrelated permissions).
|
||||
|
||||
+266
-148
@@ -40,70 +40,77 @@ kubectl get pods
|
||||
```
|
||||
|
||||
```none
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-1006230814-6winp 1/1 Running 0 11s
|
||||
nginx-deployment-1006230814-fmgu3 1/1 Running 0 11s
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-67d4bdd6f5-cx2nz 1/1 Running 0 13s
|
||||
nginx-deployment-67d4bdd6f5-w6kd7 1/1 Running 0 13s
|
||||
```
|
||||
|
||||
We can retrieve a lot more information about each of these pods using `kubectl describe pod`. For example:
|
||||
|
||||
```shell
|
||||
kubectl describe pod nginx-deployment-1006230814-6winp
|
||||
kubectl describe pod nginx-deployment-67d4bdd6f5-w6kd7
|
||||
```
|
||||
|
||||
```none
|
||||
Name: nginx-deployment-1006230814-6winp
|
||||
Namespace: default
|
||||
Node: kubernetes-node-wul5/10.240.0.9
|
||||
Start Time: Thu, 24 Mar 2016 01:39:49 +0000
|
||||
Labels: app=nginx,pod-template-hash=1006230814
|
||||
Annotations: kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-deployment-1956810328","uid":"14e607e7-8ba1-11e7-b5cb-fa16" ...
|
||||
Status: Running
|
||||
IP: 10.244.0.6
|
||||
Controllers: ReplicaSet/nginx-deployment-1006230814
|
||||
Name: nginx-deployment-67d4bdd6f5-w6kd7
|
||||
Namespace: default
|
||||
Priority: 0
|
||||
Node: kube-worker-1/192.168.0.113
|
||||
Start Time: Thu, 17 Feb 2022 16:51:01 -0500
|
||||
Labels: app=nginx
|
||||
pod-template-hash=67d4bdd6f5
|
||||
Annotations: <none>
|
||||
Status: Running
|
||||
IP: 10.88.0.3
|
||||
IPs:
|
||||
IP: 10.88.0.3
|
||||
IP: 2001:db8::1
|
||||
Controlled By: ReplicaSet/nginx-deployment-67d4bdd6f5
|
||||
Containers:
|
||||
nginx:
|
||||
Container ID: docker://90315cc9f513c724e9957a4788d3e625a078de84750f244a40f97ae355eb1149
|
||||
Image: nginx
|
||||
Image ID: docker://6f62f48c4e55d700cf3eb1b5e33fa051802986b77b874cc351cce539e5163707
|
||||
Port: 80/TCP
|
||||
QoS Tier:
|
||||
cpu: Guaranteed
|
||||
memory: Guaranteed
|
||||
Container ID: containerd://5403af59a2b46ee5a23fb0ae4b1e077f7ca5c5fb7af16e1ab21c00e0e616462a
|
||||
Image: nginx
|
||||
Image ID: docker.io/library/nginx@sha256:2834dc507516af02784808c5f48b7cbe38b8ed5d0f4837f16e78d00deb7e7767
|
||||
Port: 80/TCP
|
||||
Host Port: 0/TCP
|
||||
State: Running
|
||||
Started: Thu, 17 Feb 2022 16:51:05 -0500
|
||||
Ready: True
|
||||
Restart Count: 0
|
||||
Limits:
|
||||
cpu: 500m
|
||||
memory: 128Mi
|
||||
cpu: 500m
|
||||
memory: 128Mi
|
||||
Requests:
|
||||
memory: 128Mi
|
||||
cpu: 500m
|
||||
State: Running
|
||||
Started: Thu, 24 Mar 2016 01:39:51 +0000
|
||||
Ready: True
|
||||
Restart Count: 0
|
||||
Environment: <none>
|
||||
cpu: 500m
|
||||
memory: 128Mi
|
||||
Environment: <none>
|
||||
Mounts:
|
||||
/var/run/secrets/kubernetes.io/serviceaccount from default-token-5kdvl (ro)
|
||||
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-bgsgp (ro)
|
||||
Conditions:
|
||||
Type Status
|
||||
Initialized True
|
||||
Ready True
|
||||
PodScheduled True
|
||||
Type Status
|
||||
Initialized True
|
||||
Ready True
|
||||
ContainersReady True
|
||||
PodScheduled True
|
||||
Volumes:
|
||||
default-token-4bcbi:
|
||||
Type: Secret (a volume populated by a Secret)
|
||||
SecretName: default-token-4bcbi
|
||||
Optional: false
|
||||
QoS Class: Guaranteed
|
||||
Node-Selectors: <none>
|
||||
Tolerations: <none>
|
||||
kube-api-access-bgsgp:
|
||||
Type: Projected (a volume that contains injected data from multiple sources)
|
||||
TokenExpirationSeconds: 3607
|
||||
ConfigMapName: kube-root-ca.crt
|
||||
ConfigMapOptional: <nil>
|
||||
DownwardAPI: true
|
||||
QoS Class: Guaranteed
|
||||
Node-Selectors: <none>
|
||||
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
|
||||
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
54s 54s 1 {default-scheduler } Normal Scheduled Successfully assigned nginx-deployment-1006230814-6winp to kubernetes-node-wul5
|
||||
54s 54s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Pulling pulling image "nginx"
|
||||
53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Pulled Successfully pulled image "nginx"
|
||||
53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Created Created container with docker id 90315cc9f513
|
||||
53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Started Started container with docker id 90315cc9f513
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal Scheduled 34s default-scheduler Successfully assigned default/nginx-deployment-67d4bdd6f5-w6kd7 to kube-worker-1
|
||||
Normal Pulling 31s kubelet Pulling image "nginx"
|
||||
Normal Pulled 30s kubelet Successfully pulled image "nginx" in 1.146417389s
|
||||
Normal Created 30s kubelet Created container nginx
|
||||
Normal Started 30s kubelet Started container nginx
|
||||
```
|
||||
|
||||
Here you can see configuration information about the container(s) and Pod (labels, resource requirements, etc.), as well as status information about the container(s) and Pod (state, readiness, restart count, events, etc.).
|
||||
@@ -203,18 +210,22 @@ kubectl get pod nginx-deployment-1006230814-6winp -o yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
annotations:
|
||||
kubernetes.io/created-by: |
|
||||
{"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-deployment-1006230814","uid":"4c84c175-f161-11e5-9a78-42010af00005","apiVersion":"extensions","resourceVersion":"133434"}}
|
||||
creationTimestamp: 2016-03-24T01:39:50Z
|
||||
generateName: nginx-deployment-1006230814-
|
||||
creationTimestamp: "2022-02-17T21:51:01Z"
|
||||
generateName: nginx-deployment-67d4bdd6f5-
|
||||
labels:
|
||||
app: nginx
|
||||
pod-template-hash: "1006230814"
|
||||
name: nginx-deployment-1006230814-6winp
|
||||
pod-template-hash: 67d4bdd6f5
|
||||
name: nginx-deployment-67d4bdd6f5-w6kd7
|
||||
namespace: default
|
||||
resourceVersion: "133447"
|
||||
uid: 4c879808-f161-11e5-9a78-42010af00005
|
||||
ownerReferences:
|
||||
- apiVersion: apps/v1
|
||||
blockOwnerDeletion: true
|
||||
controller: true
|
||||
kind: ReplicaSet
|
||||
name: nginx-deployment-67d4bdd6f5
|
||||
uid: 7d41dfd4-84c0-4be4-88ab-cedbe626ad82
|
||||
resourceVersion: "1364"
|
||||
uid: a6501da1-0447-4262-98eb-c03d4002222e
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
@@ -231,42 +242,88 @@ spec:
|
||||
cpu: 500m
|
||||
memory: 128Mi
|
||||
terminationMessagePath: /dev/termination-log
|
||||
terminationMessagePolicy: File
|
||||
volumeMounts:
|
||||
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
|
||||
name: default-token-4bcbi
|
||||
name: kube-api-access-bgsgp
|
||||
readOnly: true
|
||||
dnsPolicy: ClusterFirst
|
||||
nodeName: kubernetes-node-wul5
|
||||
enableServiceLinks: true
|
||||
nodeName: kube-worker-1
|
||||
preemptionPolicy: PreemptLowerPriority
|
||||
priority: 0
|
||||
restartPolicy: Always
|
||||
schedulerName: default-scheduler
|
||||
securityContext: {}
|
||||
serviceAccount: default
|
||||
serviceAccountName: default
|
||||
terminationGracePeriodSeconds: 30
|
||||
tolerations:
|
||||
- effect: NoExecute
|
||||
key: node.kubernetes.io/not-ready
|
||||
operator: Exists
|
||||
tolerationSeconds: 300
|
||||
- effect: NoExecute
|
||||
key: node.kubernetes.io/unreachable
|
||||
operator: Exists
|
||||
tolerationSeconds: 300
|
||||
volumes:
|
||||
- name: default-token-4bcbi
|
||||
secret:
|
||||
secretName: default-token-4bcbi
|
||||
- name: kube-api-access-bgsgp
|
||||
projected:
|
||||
defaultMode: 420
|
||||
sources:
|
||||
- serviceAccountToken:
|
||||
expirationSeconds: 3607
|
||||
path: token
|
||||
- configMap:
|
||||
items:
|
||||
- key: ca.crt
|
||||
path: ca.crt
|
||||
name: kube-root-ca.crt
|
||||
- downwardAPI:
|
||||
items:
|
||||
- fieldRef:
|
||||
apiVersion: v1
|
||||
fieldPath: metadata.namespace
|
||||
path: namespace
|
||||
status:
|
||||
conditions:
|
||||
- lastProbeTime: null
|
||||
lastTransitionTime: 2016-03-24T01:39:51Z
|
||||
lastTransitionTime: "2022-02-17T21:51:01Z"
|
||||
status: "True"
|
||||
type: Initialized
|
||||
- lastProbeTime: null
|
||||
lastTransitionTime: "2022-02-17T21:51:06Z"
|
||||
status: "True"
|
||||
type: Ready
|
||||
- lastProbeTime: null
|
||||
lastTransitionTime: "2022-02-17T21:51:06Z"
|
||||
status: "True"
|
||||
type: ContainersReady
|
||||
- lastProbeTime: null
|
||||
lastTransitionTime: "2022-02-17T21:51:01Z"
|
||||
status: "True"
|
||||
type: PodScheduled
|
||||
containerStatuses:
|
||||
- containerID: docker://90315cc9f513c724e9957a4788d3e625a078de84750f244a40f97ae355eb1149
|
||||
image: nginx
|
||||
imageID: docker://6f62f48c4e55d700cf3eb1b5e33fa051802986b77b874cc351cce539e5163707
|
||||
- containerID: containerd://5403af59a2b46ee5a23fb0ae4b1e077f7ca5c5fb7af16e1ab21c00e0e616462a
|
||||
image: docker.io/library/nginx:latest
|
||||
imageID: docker.io/library/nginx@sha256:2834dc507516af02784808c5f48b7cbe38b8ed5d0f4837f16e78d00deb7e7767
|
||||
lastState: {}
|
||||
name: nginx
|
||||
ready: true
|
||||
restartCount: 0
|
||||
started: true
|
||||
state:
|
||||
running:
|
||||
startedAt: 2016-03-24T01:39:51Z
|
||||
hostIP: 10.240.0.9
|
||||
startedAt: "2022-02-17T21:51:05Z"
|
||||
hostIP: 192.168.0.113
|
||||
phase: Running
|
||||
podIP: 10.244.0.6
|
||||
startTime: 2016-03-24T01:39:49Z
|
||||
podIP: 10.88.0.3
|
||||
podIPs:
|
||||
- ip: 10.88.0.3
|
||||
- ip: 2001:db8::1
|
||||
qosClass: Guaranteed
|
||||
startTime: "2022-02-17T21:51:01Z"
|
||||
```
|
||||
|
||||
## Example: debugging a down/unreachable node
|
||||
@@ -279,116 +336,177 @@ kubectl get nodes
|
||||
|
||||
```none
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
kubernetes-node-861h NotReady <none> 1h v1.13.0
|
||||
kubernetes-node-bols Ready <none> 1h v1.13.0
|
||||
kubernetes-node-st6x Ready <none> 1h v1.13.0
|
||||
kubernetes-node-unaj Ready <none> 1h v1.13.0
|
||||
kube-worker-1 NotReady <none> 1h v1.23.3
|
||||
kubernetes-node-bols Ready <none> 1h v1.23.3
|
||||
kubernetes-node-st6x Ready <none> 1h v1.23.3
|
||||
kubernetes-node-unaj Ready <none> 1h v1.23.3
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl describe node kubernetes-node-861h
|
||||
kubectl describe node kube-worker-1
|
||||
```
|
||||
|
||||
```none
|
||||
Name: kubernetes-node-861h
|
||||
Role
|
||||
Labels: kubernetes.io/arch=amd64
|
||||
kubernetes.io/os=linux
|
||||
kubernetes.io/hostname=kubernetes-node-861h
|
||||
Annotations: node.alpha.kubernetes.io/ttl=0
|
||||
volumes.kubernetes.io/controller-managed-attach-detach=true
|
||||
Taints: <none>
|
||||
CreationTimestamp: Mon, 04 Sep 2017 17:13:23 +0800
|
||||
Phase:
|
||||
Name: kube-worker-1
|
||||
Roles: <none>
|
||||
Labels: beta.kubernetes.io/arch=amd64
|
||||
beta.kubernetes.io/os=linux
|
||||
kubernetes.io/arch=amd64
|
||||
kubernetes.io/hostname=kube-worker-1
|
||||
kubernetes.io/os=linux
|
||||
Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
|
||||
node.alpha.kubernetes.io/ttl: 0
|
||||
volumes.kubernetes.io/controller-managed-attach-detach: true
|
||||
CreationTimestamp: Thu, 17 Feb 2022 16:46:30 -0500
|
||||
Taints: node.kubernetes.io/unreachable:NoExecute
|
||||
node.kubernetes.io/unreachable:NoSchedule
|
||||
Unschedulable: false
|
||||
Lease:
|
||||
HolderIdentity: kube-worker-1
|
||||
AcquireTime: <unset>
|
||||
RenewTime: Thu, 17 Feb 2022 17:13:09 -0500
|
||||
Conditions:
|
||||
Type Status LastHeartbeatTime LastTransitionTime Reason Message
|
||||
---- ------ ----------------- ------------------ ------ -------
|
||||
OutOfDisk Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status.
|
||||
MemoryPressure Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status.
|
||||
DiskPressure Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status.
|
||||
Ready Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status.
|
||||
Addresses: 10.240.115.55,104.197.0.26
|
||||
Type Status LastHeartbeatTime LastTransitionTime Reason Message
|
||||
---- ------ ----------------- ------------------ ------ -------
|
||||
NetworkUnavailable False Thu, 17 Feb 2022 17:09:13 -0500 Thu, 17 Feb 2022 17:09:13 -0500 WeaveIsUp Weave pod has set this
|
||||
MemoryPressure Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status.
|
||||
DiskPressure Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status.
|
||||
PIDPressure Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status.
|
||||
Ready Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status.
|
||||
Addresses:
|
||||
InternalIP: 192.168.0.113
|
||||
Hostname: kube-worker-1
|
||||
Capacity:
|
||||
cpu: 2
|
||||
hugePages: 0
|
||||
memory: 4046788Ki
|
||||
pods: 110
|
||||
cpu: 2
|
||||
ephemeral-storage: 15372232Ki
|
||||
hugepages-2Mi: 0
|
||||
memory: 2025188Ki
|
||||
pods: 110
|
||||
Allocatable:
|
||||
cpu: 1500m
|
||||
hugePages: 0
|
||||
memory: 1479263Ki
|
||||
pods: 110
|
||||
cpu: 2
|
||||
ephemeral-storage: 14167048988
|
||||
hugepages-2Mi: 0
|
||||
memory: 1922788Ki
|
||||
pods: 110
|
||||
System Info:
|
||||
Machine ID: 8e025a21a4254e11b028584d9d8b12c4
|
||||
System UUID: 349075D1-D169-4F25-9F2A-E886850C47E3
|
||||
Boot ID: 5cd18b37-c5bd-4658-94e0-e436d3f110e0
|
||||
Kernel Version: 4.4.0-31-generic
|
||||
OS Image: Debian GNU/Linux 8 (jessie)
|
||||
Operating System: linux
|
||||
Architecture: amd64
|
||||
Container Runtime Version: docker://1.12.5
|
||||
Kubelet Version: v1.6.9+a3d1dfa6f4335
|
||||
Kube-Proxy Version: v1.6.9+a3d1dfa6f4335
|
||||
ExternalID: 15233045891481496305
|
||||
Non-terminated Pods: (9 in total)
|
||||
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
|
||||
--------- ---- ------------ ---------- --------------- -------------
|
||||
......
|
||||
Machine ID: 9384e2927f544209b5d7b67474bbf92b
|
||||
System UUID: aa829ca9-73d7-064d-9019-df07404ad448
|
||||
Boot ID: 5a295a03-aaca-4340-af20-1327fa5dab5c
|
||||
Kernel Version: 5.13.0-28-generic
|
||||
OS Image: Ubuntu 21.10
|
||||
Operating System: linux
|
||||
Architecture: amd64
|
||||
Container Runtime Version: containerd://1.5.9
|
||||
Kubelet Version: v1.23.3
|
||||
Kube-Proxy Version: v1.23.3
|
||||
Non-terminated Pods: (4 in total)
|
||||
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits Age
|
||||
--------- ---- ------------ ---------- --------------- ------------- ---
|
||||
default nginx-deployment-67d4bdd6f5-cx2nz 500m (25%) 500m (25%) 128Mi (6%) 128Mi (6%) 23m
|
||||
default nginx-deployment-67d4bdd6f5-w6kd7 500m (25%) 500m (25%) 128Mi (6%) 128Mi (6%) 23m
|
||||
kube-system kube-proxy-dnxbz 0 (0%) 0 (0%) 0 (0%) 0 (0%) 28m
|
||||
kube-system weave-net-gjxxp 100m (5%) 0 (0%) 200Mi (10%) 0 (0%) 28m
|
||||
Allocated resources:
|
||||
(Total limits may be over 100 percent, i.e., overcommitted.)
|
||||
CPU Requests CPU Limits Memory Requests Memory Limits
|
||||
------------ ---------- --------------- -------------
|
||||
900m (60%) 2200m (146%) 1009286400 (66%) 5681286400 (375%)
|
||||
Events: <none>
|
||||
Resource Requests Limits
|
||||
-------- -------- ------
|
||||
cpu 1100m (55%) 1 (50%)
|
||||
memory 456Mi (24%) 256Mi (13%)
|
||||
ephemeral-storage 0 (0%) 0 (0%)
|
||||
hugepages-2Mi 0 (0%) 0 (0%)
|
||||
Events:
|
||||
...
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get node kubernetes-node-861h -o yaml
|
||||
kubectl get node kube-worker-1 -o yaml
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Node
|
||||
metadata:
|
||||
creationTimestamp: 2015-07-10T21:32:29Z
|
||||
annotations:
|
||||
kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
|
||||
node.alpha.kubernetes.io/ttl: "0"
|
||||
volumes.kubernetes.io/controller-managed-attach-detach: "true"
|
||||
creationTimestamp: "2022-02-17T21:46:30Z"
|
||||
labels:
|
||||
kubernetes.io/hostname: kubernetes-node-861h
|
||||
name: kubernetes-node-861h
|
||||
resourceVersion: "757"
|
||||
uid: 2a69374e-274b-11e5-a234-42010af0d969
|
||||
spec:
|
||||
externalID: "15233045891481496305"
|
||||
podCIDR: 10.244.0.0/24
|
||||
providerID: gce://striped-torus-760/us-central1-b/kubernetes-node-861h
|
||||
beta.kubernetes.io/arch: amd64
|
||||
beta.kubernetes.io/os: linux
|
||||
kubernetes.io/arch: amd64
|
||||
kubernetes.io/hostname: kube-worker-1
|
||||
kubernetes.io/os: linux
|
||||
name: kube-worker-1
|
||||
resourceVersion: "4026"
|
||||
uid: 98efe7cb-2978-4a0b-842a-1a7bf12c05f8
|
||||
spec: {}
|
||||
status:
|
||||
addresses:
|
||||
- address: 10.240.115.55
|
||||
- address: 192.168.0.113
|
||||
type: InternalIP
|
||||
- address: 104.197.0.26
|
||||
type: ExternalIP
|
||||
- address: kube-worker-1
|
||||
type: Hostname
|
||||
allocatable:
|
||||
cpu: "2"
|
||||
ephemeral-storage: "14167048988"
|
||||
hugepages-2Mi: "0"
|
||||
memory: 1922788Ki
|
||||
pods: "110"
|
||||
capacity:
|
||||
cpu: "1"
|
||||
memory: 3800808Ki
|
||||
pods: "100"
|
||||
cpu: "2"
|
||||
ephemeral-storage: 15372232Ki
|
||||
hugepages-2Mi: "0"
|
||||
memory: 2025188Ki
|
||||
pods: "110"
|
||||
conditions:
|
||||
- lastHeartbeatTime: 2015-07-10T21:34:32Z
|
||||
lastTransitionTime: 2015-07-10T21:35:15Z
|
||||
reason: Kubelet stopped posting node status.
|
||||
status: Unknown
|
||||
- lastHeartbeatTime: "2022-02-17T22:20:32Z"
|
||||
lastTransitionTime: "2022-02-17T22:20:32Z"
|
||||
message: Weave pod has set this
|
||||
reason: WeaveIsUp
|
||||
status: "False"
|
||||
type: NetworkUnavailable
|
||||
- lastHeartbeatTime: "2022-02-17T22:20:15Z"
|
||||
lastTransitionTime: "2022-02-17T22:13:25Z"
|
||||
message: kubelet has sufficient memory available
|
||||
reason: KubeletHasSufficientMemory
|
||||
status: "False"
|
||||
type: MemoryPressure
|
||||
- lastHeartbeatTime: "2022-02-17T22:20:15Z"
|
||||
lastTransitionTime: "2022-02-17T22:13:25Z"
|
||||
message: kubelet has no disk pressure
|
||||
reason: KubeletHasNoDiskPressure
|
||||
status: "False"
|
||||
type: DiskPressure
|
||||
- lastHeartbeatTime: "2022-02-17T22:20:15Z"
|
||||
lastTransitionTime: "2022-02-17T22:13:25Z"
|
||||
message: kubelet has sufficient PID available
|
||||
reason: KubeletHasSufficientPID
|
||||
status: "False"
|
||||
type: PIDPressure
|
||||
- lastHeartbeatTime: "2022-02-17T22:20:15Z"
|
||||
lastTransitionTime: "2022-02-17T22:15:15Z"
|
||||
message: kubelet is posting ready status. AppArmor enabled
|
||||
reason: KubeletReady
|
||||
status: "True"
|
||||
type: Ready
|
||||
daemonEndpoints:
|
||||
kubeletEndpoint:
|
||||
Port: 10250
|
||||
nodeInfo:
|
||||
bootID: 4e316776-b40d-4f78-a4ea-ab0d73390897
|
||||
containerRuntimeVersion: docker://Unknown
|
||||
kernelVersion: 3.16.0-0.bpo.4-amd64
|
||||
kubeProxyVersion: v0.21.1-185-gffc5a86098dc01
|
||||
kubeletVersion: v0.21.1-185-gffc5a86098dc01
|
||||
machineID: ""
|
||||
osImage: Debian GNU/Linux 7 (wheezy)
|
||||
systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E
|
||||
architecture: amd64
|
||||
bootID: 22333234-7a6b-44d4-9ce1-67e31dc7e369
|
||||
containerRuntimeVersion: containerd://1.5.9
|
||||
kernelVersion: 5.13.0-28-generic
|
||||
kubeProxyVersion: v1.23.3
|
||||
kubeletVersion: v1.23.3
|
||||
machineID: 9384e2927f544209b5d7b67474bbf92b
|
||||
operatingSystem: linux
|
||||
osImage: Ubuntu 21.10
|
||||
systemUUID: aa829ca9-73d7-064d-9019-df07404ad448
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
||||
@@ -75,6 +75,12 @@ only the termination message:
|
||||
|
||||
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
|
||||
|
||||
If you are running a multi-container pod, you can use a Go template to include the container's name. By doing so, you can discover which of the containers is failing:
|
||||
|
||||
```shell
|
||||
kubectl get pod multi-container-pod -o go-template='{{range .status.containerStatuses}}{{printf "%s:\n%s\n\n" .name .lastState.terminated.message}}{{end}}'
|
||||
```
|
||||
|
||||
## Customizing the termination message
|
||||
|
||||
Kubernetes retrieves termination messages from the termination message file
|
||||
|
||||
@@ -101,7 +101,7 @@ If filing a bug, please include detailed information about how to reproduce the
|
||||
problem, such as:
|
||||
|
||||
* Kubernetes version: `kubectl version`
|
||||
* Cloud provider, OS distro, network configuration, and Docker version
|
||||
* Cloud provider, OS distro, network configuration, and container runtime version
|
||||
* Steps to reproduce the problem
|
||||
|
||||
|
||||
|
||||
@@ -152,4 +152,5 @@ Some example values of `matchImages` patterns are:
|
||||
|
||||
* Read the details about `CredentialProviderConfig` in the
|
||||
[kubelet configuration API (v1alpha1) reference](/docs/reference/config-api/kubelet-config.v1alpha1/).
|
||||
* Read the [kubelet credential provider API reference (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/).
|
||||
|
||||
|
||||
@@ -95,6 +95,11 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
Or use this for detailed view of version:
|
||||
|
||||
```cmd
|
||||
kubectl version --client --output=yaml
|
||||
```
|
||||
|
||||
### Install using native package management
|
||||
|
||||
|
||||
@@ -111,6 +111,11 @@ The following methods exist for installing kubectl on macOS:
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
Or use this for detailed view of version:
|
||||
|
||||
```cmd
|
||||
kubectl version --client --output=yaml
|
||||
```
|
||||
|
||||
### Install with Homebrew on macOS
|
||||
|
||||
|
||||
@@ -66,6 +66,11 @@ The following methods exist for installing kubectl on Windows:
|
||||
```cmd
|
||||
kubectl version --client
|
||||
```
|
||||
Or use this for detailed view of version:
|
||||
|
||||
```cmd
|
||||
kubectl version --client --output=yaml
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to `PATH`.
|
||||
|
||||
@@ -442,7 +442,7 @@ datadir-zk-2 Bound pvc-bee0817e-bcb1-11e6-994f-42010a800002 20Gi R
|
||||
|
||||
The `volumeMounts` section of the `StatefulSet`'s container `template` mounts the PersistentVolumes in the ZooKeeper servers' data directories.
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
volumeMounts:
|
||||
- name: datadir
|
||||
mountPath: /var/lib/zookeeper
|
||||
@@ -661,6 +661,8 @@ Use the `kubectl rollout history` command to view a history or previous configur
|
||||
kubectl rollout history sts/zk
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
statefulsets "zk"
|
||||
REVISION
|
||||
@@ -674,6 +676,8 @@ Use the `kubectl rollout undo` command to roll back the modification.
|
||||
kubectl rollout undo sts/zk
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
statefulset.apps/zk rolled back
|
||||
```
|
||||
@@ -742,14 +746,14 @@ that your application's processes are unhealthy and it should restart them.
|
||||
The Pod `template` for the `zk` `StatefulSet` specifies a liveness probe.
|
||||
|
||||
```yaml
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- "zookeeper-ready 2181"
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 5
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- "zookeeper-ready 2181"
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 5
|
||||
```
|
||||
|
||||
The probe calls a bash script that uses the ZooKeeper `ruok` four letter
|
||||
@@ -773,7 +777,7 @@ kubectl get pod -w -l app=zk
|
||||
In another window, using the following command to delete the `zookeeper-ready` script from the file system of Pod `zk-0`.
|
||||
|
||||
```shell
|
||||
kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready
|
||||
kubectl exec zk-0 -- rm /opt/zookeeper/bin/zookeeper-ready
|
||||
```
|
||||
|
||||
When the liveness probe for the ZooKeeper process fails, Kubernetes will
|
||||
@@ -860,16 +864,16 @@ kubernetes-node-2g2d
|
||||
This is because the Pods in the `zk` `StatefulSet` have a `PodAntiAffinity` specified.
|
||||
|
||||
```yaml
|
||||
affinity:
|
||||
podAntiAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
- labelSelector:
|
||||
matchExpressions:
|
||||
- key: "app"
|
||||
operator: In
|
||||
values:
|
||||
- zk
|
||||
topologyKey: "kubernetes.io/hostname"
|
||||
affinity:
|
||||
podAntiAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
- labelSelector:
|
||||
matchExpressions:
|
||||
- key: "app"
|
||||
operator: In
|
||||
values:
|
||||
- zk
|
||||
topologyKey: "kubernetes.io/hostname"
|
||||
```
|
||||
|
||||
The `requiredDuringSchedulingIgnoredDuringExecution` field tells the
|
||||
@@ -926,6 +930,8 @@ In another terminal, use this command to get the nodes that the Pods are current
|
||||
for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
kubernetes-node-pb41
|
||||
kubernetes-node-ixsl
|
||||
@@ -939,6 +945,8 @@ drain the node on which the `zk-0` Pod is scheduled.
|
||||
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
node "kubernetes-node-pb41" cordoned
|
||||
|
||||
@@ -971,15 +979,19 @@ Keep watching the `StatefulSet`'s Pods in the first terminal and drain the node
|
||||
`zk-1` is scheduled.
|
||||
|
||||
```shell
|
||||
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" cordoned
|
||||
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
"kubernetes-node-ixsl" cordoned
|
||||
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74
|
||||
pod "zk-1" deleted
|
||||
node "kubernetes-node-ixsl" drained
|
||||
```
|
||||
|
||||
|
||||
The `zk-1` Pod cannot be scheduled because the `zk` `StatefulSet` contains a `PodAntiAffinity` rule preventing
|
||||
co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state.
|
||||
|
||||
@@ -987,6 +999,8 @@ co-location of the Pods, and as only two nodes are schedulable, the Pod will rem
|
||||
kubectl get pods -w -l app=zk
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
zk-0 1/1 Running 2 1h
|
||||
@@ -1010,13 +1024,15 @@ zk-1 0/1 Pending 0 0s
|
||||
zk-1 0/1 Pending 0 0s
|
||||
```
|
||||
|
||||
Continue to watch the Pods of the stateful set, and drain the node on which
|
||||
Continue to watch the Pods of the StatefulSet, and drain the node on which
|
||||
`zk-2` is scheduled.
|
||||
|
||||
```shell
|
||||
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
node "kubernetes-node-i4c4" cordoned
|
||||
|
||||
@@ -1060,6 +1076,8 @@ Use [`kubectl uncordon`](/docs/reference/generated/kubectl/kubectl-commands/#unc
|
||||
kubectl uncordon kubernetes-node-pb41
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
node "kubernetes-node-pb41" uncordoned
|
||||
```
|
||||
@@ -1070,6 +1088,8 @@ node "kubernetes-node-pb41" uncordoned
|
||||
kubectl get pods -w -l app=zk
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
zk-0 1/1 Running 2 1h
|
||||
@@ -1103,7 +1123,7 @@ Attempt to drain the node on which `zk-2` is scheduled.
|
||||
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
The output:
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
node "kubernetes-node-i4c4" already cordoned
|
||||
@@ -1121,6 +1141,8 @@ Uncordon the second node to allow `zk-2` to be rescheduled.
|
||||
kubectl uncordon kubernetes-node-ixsl
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
node "kubernetes-node-ixsl" uncordoned
|
||||
```
|
||||
|
||||
@@ -51,7 +51,7 @@ Por ejemplo, para descargar la versión {{< param "fullversion" >}} en Linux, es
|
||||
Valide el binario kubectl con el archivo de comprobación:
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
|
||||
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
|
||||
```
|
||||
|
||||
Si es válido, la salida es:
|
||||
@@ -191,7 +191,7 @@ A continuación, se muestran los procedimientos para configurar el autocompletad
|
||||
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
|
||||
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)
|
||||
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: コンテナランタイムインターフェイス(CRI)
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
CRIは、クラスターコンポーネントを再コンパイルすることなく、kubeletがさまざまなコンテナランタイムを使用できるようにするプラグインインターフェイスです。
|
||||
|
||||
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}とそのコンテナを起動できるように、クラスター内の各ノードで動作する{{<glossary_tooltip text="container runtime" term_id="container-runtime">}}が必要です。
|
||||
|
||||
kubeletとContainerRuntime間の通信のメインプロトコルです。
|
||||
|
||||
Kubernetes Container Runtime Interface(CRI)は、[クラスターコンポーネント](/ja/docs/concepts/overview/components/#node-components){{< glossary_tooltip text="kubelet" term_id="kubelet" >}}と{{<glossary_tooltip text="container runtime" term_id="container-runtime">}}間の通信用のメイン[gRPC](/ja/docs/concepts/overview/components/#node-components)プロトコルを定義します。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## API {#api}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
kubeletは、gRPCを介してコンテナランタイムに接続するときにクライアントとして機能します。ランタイムおよびイメージサービスエンドポイントは、コンテナランタイムで使用可能である必要があります。コンテナランタイムは、`--image-service-endpoint`および`--container-runtime-endpoint`[コマンドラインフラグ](/ja/docs/reference/command-line-tools-reference/kubelet)を使用して、kubelet内で個別に設定できます。
|
||||
|
||||
Kubernetes v{{< skew currentVersion >}}の場合、kubeletはCRI `v1`の使用を優先します。
|
||||
コンテナランタイムがCRIの`v1`をサポートしていない場合、kubeletはサポートされている古いバージョンのネゴシエーションを試みます。
|
||||
kubelet v{{< skew currentVersion >}}はCRI `v1alpha2`をネゴシエートすることもできますが、このバージョンは非推奨と見なされます。
|
||||
kubeletがサポートされているCRIバージョンをネゴシエートできない場合、kubeletはあきらめて、ノードとして登録されません。
|
||||
|
||||
## アップグレード
|
||||
|
||||
Kubernetesをアップグレードする場合、kubeletはコンポーネントの再起動時に最新のCRIバージョンを自動的に選択しようとします。
|
||||
それが失敗した場合、フォールバックは上記のように行われます。
|
||||
コンテナランタイムがアップグレードされたためにgRPCリダイヤルが必要な場合は、コンテナランタイムも最初に選択されたバージョンをサポートする必要があります。
|
||||
そうでない場合、リダイヤルは失敗することが予想されます。これには、kubeletの再起動が必要です。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- CRI[プロトコル定義](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)の詳細を学ぶ。
|
||||
@@ -163,7 +163,7 @@ persistentvolumeclaim/my-pvc created
|
||||
|
||||
これまで取り上げた例では、リソースに対して最大1つのラベルを適用してきました。リソースのセットを他のセットと区別するために、複数のラベルが必要な状況があります。
|
||||
|
||||
例えば、異なるアプリケーション間では、異なる`app`ラベルを使用したり、[ゲストブックの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)のようなマルチティアーのアプリケーションでは、各ティアーを区別する必要があります。frontendというティアーでは下記のラベルを持ちます。:
|
||||
例えば、異なるアプリケーション間では、異なる`app`ラベルを使用したり、[ゲストブックの例](https://github.com/kubernetes/examples/tree/master/guestbook/)のようなマルチティアーのアプリケーションでは、各ティアーを区別する必要があります。frontendというティアーでは下記のラベルを持ちます。:
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
|
||||
@@ -58,7 +58,7 @@ weight: 10
|
||||
|
||||
## ラベルの使用
|
||||
|
||||
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの __セマンティック属性__ を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なPodを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
|
||||
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの __セマンティック属性__ を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なPodを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/master/guestbook/)アプリも合わせてご覧ください。
|
||||
|
||||
セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ FOO_SERVICE_HOST=<サービスが実行されているホスト>
|
||||
FOO_SERVICE_PORT=<サービスが実行されているポート>
|
||||
```
|
||||
|
||||
サービスは専用のIPアドレスを持ち、[DNSアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)が有効の場合、DNSを介してコンテナで利用可能です。
|
||||
サービスは専用のIPアドレスを持ち、[DNSアドオン](http://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/)が有効の場合、DNSを介してコンテナで利用可能です。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -139,7 +139,7 @@ Service IPは完全に仮想的なもので、ホスト側のネットワーク
|
||||
## Serviceにアクセスする
|
||||
|
||||
Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。
|
||||
前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。
|
||||
前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)を必要とします。
|
||||
{{< note >}}
|
||||
サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。
|
||||
{{< /note >}}
|
||||
@@ -234,7 +234,7 @@ Address 1: 10.0.162.149
|
||||
* 証明書を使用するように構成されたnginxサーバー
|
||||
* Podが証明書にアクセスできるようにする[Secret](/ja/docs/concepts/configuration/secret/)
|
||||
|
||||
これらはすべて[nginx httpsの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)から取得できます。
|
||||
これらはすべて[nginx httpsの例](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/)から取得できます。
|
||||
これにはツールをインストールする必要があります。
|
||||
これらをインストールしたくない場合は、後で手動の手順に従ってください。つまり:
|
||||
|
||||
@@ -309,7 +309,7 @@ nginxsecret kubernetes.io/tls 2 1m
|
||||
nginx-secure-appマニフェストに関する注目すべき点:
|
||||
|
||||
- 同じファイルにDeploymentとServiceの両方が含まれています。
|
||||
- [nginxサーバー](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)はポート80のHTTPトラフィックと443のHTTPSトラフィックを処理し、nginx Serviceは両方のポートを公開します。
|
||||
- [nginxサーバー](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf)はポート80のHTTPトラフィックと443のHTTPSトラフィックを処理し、nginx Serviceは両方のポートを公開します。
|
||||
- 各コンテナは`/etc/nginx/ssl`にマウントされたボリュームを介してキーにアクセスできます。
|
||||
これは、nginxサーバーが起動する*前に*セットアップされます。
|
||||
|
||||
|
||||
@@ -280,7 +280,7 @@ Kubernetesは、Serviceオブジェクトを見つけ出すために2つの主
|
||||
|
||||
PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに対して、環境変数のセットを追加します。
|
||||
これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数(
|
||||
[makeLinkVariables関数](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。
|
||||
[makeLinkVariables関数](https://releases.k8s.io/{{< param "fullversion" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。
|
||||
|
||||
例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`redis-master`というServiceは、下記のような環境変数を生成します。
|
||||
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
title: 投影ボリューム
|
||||
content_type: concept
|
||||
weight: 21 # just after persistent volumes
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
このドキュメントでは、Kubernetesの*投影ボリューム*について説明します。[ボリューム](/docs/concepts/storage/volumes/)に精通していることをお勧めします。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 概要
|
||||
|
||||
ボリュームは、いくつかの既存の`投影`ボリュームソースを同じディレクトリにマップします。
|
||||
|
||||
現在、次のタイプのボリュームソースを投影できます。
|
||||
|
||||
* [`secret`](/docs/concepts/storage/volumes/#secret)
|
||||
* [`downwardAPI`](/docs/concepts/storage/volumes/#downwardapi)
|
||||
* [`configMap`](/docs/concepts/storage/volumes/#configmap)
|
||||
* `serviceAccountToken`
|
||||
|
||||
すべてのソースは、Podと同じnamespaceにある必要があります。詳細は[all-in-one volume](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md)デザインドキュメントを参照してください。
|
||||
|
||||
### secret、downwardAPI、およびconfigMapを使用した構成例 {#example-configuration-secret-downwardapi-configmap}
|
||||
|
||||
{{< codenew file="pods/storage/projected-secret-downwardapi-configmap.yaml" >}}
|
||||
|
||||
### 構成例:デフォルト以外のアクセス許可モードが設定されたsecret {#example-configuration-secrets-nondefault-permission-mode}
|
||||
|
||||
{{< codenew file="pods/storage/projected-secrets-nondefault-permission-mode.yaml" >}}
|
||||
|
||||
各投影ボリュームソースは、specの`sources`にリストされています。パラメーターは、2つの例外を除いてほぼ同じです。
|
||||
|
||||
* secretについて、ConfigMapの命名と一致するように`secretName`フィールドが`name`に変更されました。
|
||||
* `defaultMode`はprojectedレベルでのみ指定でき、各ボリュームソースには指定できません。ただし上に示したように、個々の投影ごとに`mode`を明示的に設定できます。
|
||||
|
||||
`TokenRequestProjection`機能が有効になっている場合、現在の[サービスアカウントトークン](/ja/docs/reference/access-authn-authz/authentication/#service-account-token)を指定されたパスのPodに挿入できます。例えば:
|
||||
|
||||
{{< codenew file="pods/storage/projected-service-account-token.yaml" >}}
|
||||
|
||||
この例のPodには、挿入されたサービスアカウントトークンを含む投影ボリュームがあります。このトークンはPodのコンテナがKubernetes APIサーバーにアクセスするために使用できます。この`audience`フィールドにはトークンの受信対象者が含まれています。トークンの受信者は、トークンの`audience`フィールドで指定された識別子で自分自身であるかを識別します。そうでない場合はトークンを拒否します。このフィールドはオプションで、デフォルトではAPIサーバーの識別子が指定されます。
|
||||
|
||||
`expirationSeconds`はサービスアカウントトークンが有効であると予想される期間です。
|
||||
デフォルトは1時間で、最低でも10分(600秒)でなければなりません。
|
||||
管理者は、APIサーバーに`--service-account-max-token-expiration`オプションを指定することで、その最大値を制限することも可能です。
|
||||
`path`フィールドは、投影ボリュームのマウントポイントへの相対パスを指定します。
|
||||
|
||||
|
||||
{{< note >}}
|
||||
投影ボリュームソースを[`subPath`](/docs/concepts/storage/volumes/#using-subpath)ボリュームマウントとして使用しているコンテナは、それらのボリュームソースの更新を受信しません。
|
||||
{{< /note >}}
|
||||
|
||||
## SecurityContextの相互作用
|
||||
|
||||
サービスアカウントの投影ボリューム拡張でのファイル権限処理の[提案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal)により、正しい所有者権限が設定された投影ファイルが導入されました。
|
||||
|
||||
### Linux
|
||||
|
||||
投影ボリュームがあり、Podの[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)に`RunAsUser`が設定されているLinux Podでは、投影されたファイルには、コンテナユーザーの所有権を含む正しい所有権が設定されます。
|
||||
|
||||
### Windows
|
||||
|
||||
投影ボリュームを持ち、Podの`SecurityContext`で`RunAsUsername`を設定したWindows Podでは、Windowsのユーザーアカウント管理方法により所有権が強制されません。
|
||||
Windowsは、ローカルユーザーとグループアカウントをセキュリティアカウントマネージャー(SAM)と呼ばれるデータベースファイルに保存し、管理します。
|
||||
各コンテナはSAMデータベースの独自のインスタンスを維持し、コンテナの実行中はホストはそのインスタンスを見ることができません。
|
||||
Windowsコンテナは、OSのユーザーモード部分をホストから分離して実行するように設計されており、そのため仮想SAMデータベースを維持することになります。
|
||||
そのため、ホスト上で動作するkubeletには、仮想化されたコンテナアカウントのホストファイル所有権を動的に設定する機能がありません。
|
||||
ホストマシン上のファイルをコンテナと共有する場合は、`C:\`以外の独自のボリュームマウントに配置することをお勧めします。
|
||||
|
||||
デフォルトでは、投影ボリュームファイルの例に示されているように、投影されたファイルには次の所有権があります。
|
||||
```powershell
|
||||
PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List
|
||||
|
||||
Path : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt
|
||||
Owner : BUILTIN\Administrators
|
||||
Group : NT AUTHORITY\SYSTEM
|
||||
Access : NT AUTHORITY\SYSTEM Allow FullControl
|
||||
BUILTIN\Administrators Allow FullControl
|
||||
BUILTIN\Users Allow ReadAndExecute, Synchronize
|
||||
Audit :
|
||||
Sddl : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)
|
||||
```
|
||||
これは、`ContainerAdministrator`のようなすべての管理者ユーザーが読み取り、書き込み、および実行アクセス権を持ち、非管理者ユーザーが読み取りおよび実行アクセス権を持つことを意味します。
|
||||
|
||||
{{< note >}}
|
||||
一般に、コンテナにホストへのアクセスを許可することは、潜在的なセキュリティの悪用への扉を開く可能性があるため、お勧めできません。
|
||||
|
||||
Windows Podの`SecurityContext`に`RunAsUser`を指定して作成すると、Podは`ContainerCreating`で永久に固まります。したがって、Windows PodでLinux専用の`RunAsUser`オプションを使用しないことをお勧めします。
|
||||
{{< /note >}}
|
||||
@@ -29,7 +29,7 @@ StatefulSetは下記の1つ以上の項目を要求するアプリケーショ
|
||||
|
||||
## 制限事項
|
||||
|
||||
* 提供されたPodのストレージは、要求された`storage class`にもとづいて[PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)によってプロビジョンされるか、管理者によって事前にプロビジョンされなくてはなりません。
|
||||
* 提供されたPodのストレージは、要求された`storage class`にもとづいて[PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)によってプロビジョンされるか、管理者によって事前にプロビジョンされなくてはなりません。
|
||||
* StatefulSetの削除もしくはスケールダウンをすることにより、StatefulSetに関連したボリュームは削除*されません* 。 これはデータ安全性のためで、関連するStatefulSetのリソース全てを自動的に削除するよりもたいてい有効です。
|
||||
* StatefulSetは現在、Podのネットワークアイデンティティーに責務をもつために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を要求します。ユーザーはこのServiceを作成する責任があります。
|
||||
* StatefulSetは、StatefulSetが削除されたときにPodの停止を行うことを保証していません。StatefulSetにおいて、規則的で安全なPodの停止を行う場合、削除のために事前にそのStatefulSetの数を0にスケールダウンさせることが可能です。
|
||||
|
||||
@@ -105,7 +105,7 @@ APIサーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token
|
||||
|
||||
ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`kubeadm`でこれらのトークンを管理する方法については、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)を参照してください。
|
||||
|
||||
### サービスアカウントトークン
|
||||
### サービスアカウントトークン {#service-account-token}
|
||||
|
||||
サービスアカウントは、自動的に有効化される認証機能で、署名されたBearerトークンを使ってリクエストを検証します。このプラグインは、オプションとして2つのフラグを取ります。
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ This page describes how to run a cluster in multiple zones.
|
||||
## 始めに
|
||||
|
||||
Kubernetes 1.2より、複数のゾーンにおいて単一のクラスターを運用するサポートが追加されました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。
|
||||
これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。
|
||||
これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。
|
||||
完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に1つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。
|
||||
|
||||
マルチゾーンサポートは故意に限定されています: 1つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。
|
||||
|
||||
@@ -53,9 +53,9 @@ export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
|
||||
|
||||
新しいクラスターを試すには、[簡単なnginxの例](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。
|
||||
|
||||
"Guestbook"アプリケーションは、Kubernetesを始めるもう一つのポピュラーな例です: [guestbookの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
|
||||
"Guestbook"アプリケーションは、Kubernetesを始めるもう一つのポピュラーな例です: [guestbookの例](https://github.com/kubernetes/examples/tree/master/guestbook/)
|
||||
|
||||
より完全なアプリケーションについては、[examplesディレクトリ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)を参照してください。
|
||||
より完全なアプリケーションについては、[examplesディレクトリ](https://github.com/kubernetes/examples/tree/master/)を参照してください。
|
||||
|
||||
## クラスターのスケーリング
|
||||
|
||||
|
||||
@@ -146,7 +146,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh
|
||||
|
||||
Then, see [a simple nginx example](/ja/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
|
||||
|
||||
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
|
||||
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/master/). The [guestbook example](https://github.com/kubernetes/examples/tree/master/guestbook/) is a good "getting started" walkthrough.
|
||||
|
||||
## クラスターの解体
|
||||
|
||||
|
||||
@@ -0,0 +1,235 @@
|
||||
---
|
||||
title: 証明書
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
クライアント証明書認証を使用する場合、`easyrsa`,`openssl`または`cfssl`を使って手動で証明書を生成することができます。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
### easyrsa
|
||||
|
||||
**easyrsa**はクラスターの証明書を手動で生成することができます。
|
||||
|
||||
1. パッチが適用されたバージョンのeasyrsa3をダウンロードし、解凍し、初期化します。
|
||||
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
|
||||
tar xzf easy-rsa.tar.gz
|
||||
cd easy-rsa-master/easyrsa3
|
||||
./easyrsa init-pki
|
||||
1. 新しい認証局(CA)を生成します。
|
||||
`req-cn`はCAの新しいルート証明書のコモンネーム(CN)を指定します。
|
||||
|
||||
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
|
||||
1. サーバー証明書と鍵を生成します。
|
||||
引数`--subject-alt-name`は、APIサーバーがアクセス可能なIPとDNS名を設定します。
|
||||
`MASTER_CLUSTER_IP`は通常、APIサーバーとコントローラーマネージャーコンポーネントの両方で`--service-cluster-ip-range`引数に指定したサービスCIDRの最初のIPとなります。
|
||||
引数`--days`は、証明書の有効期限が切れるまでの日数を設定するために使用します。
|
||||
また、以下のサンプルでは、デフォルトのDNSドメイン名として`cluster.local`を使用することを想定しています。
|
||||
|
||||
./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
|
||||
"IP:${MASTER_CLUSTER_IP},"\
|
||||
"DNS:kubernetes,"\
|
||||
"DNS:kubernetes.default,"\
|
||||
"DNS:kubernetes.default.svc,"\
|
||||
"DNS:kubernetes.default.svc.cluster,"\
|
||||
"DNS:kubernetes.default.svc.cluster.local" \
|
||||
--days=10000 \
|
||||
build-server-full server nopass
|
||||
1. `pki/ca.crt`,`pki/issued/server.crt`,`pki/private/server.key`を自分のディレクトリにコピーします。
|
||||
1. APIサーバーのスタートパラメーターに以下のパラメーターを記入し、追加します。
|
||||
|
||||
--client-ca-file=/yourdirectory/ca.crt
|
||||
--tls-cert-file=/yourdirectory/server.crt
|
||||
--tls-private-key-file=/yourdirectory/server.key
|
||||
|
||||
### openssl
|
||||
|
||||
**openssl**は、クラスター用の証明書を手動で生成することができます。
|
||||
|
||||
1. 2048bitのca.keyを生成します:
|
||||
|
||||
openssl genrsa -out ca.key 2048
|
||||
1. ca.keyに従ってca.crtを生成します(-daysで証明書の有効期限を設定します)。
|
||||
|
||||
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
|
||||
1. 2048bitでserver.keyを生成します:
|
||||
|
||||
openssl genrsa -out server.key 2048
|
||||
1. 証明書署名要求(CSR)を生成するための設定ファイルを作成します。
|
||||
角括弧で囲まれた値(例:`<MASTER_IP>`)は必ず実際の値に置き換えてから、ファイル(例:`csr.conf`)に保存してください。`MASTER_CLUSTER_IP`の値は、前のサブセクションで説明したように、APIサーバーのサービスクラスターのIPであることに注意してください。また、以下のサンプルでは、デフォルトのDNSドメイン名として`cluster.local`を使用することを想定しています。
|
||||
|
||||
[ req ]
|
||||
default_bits = 2048
|
||||
prompt = no
|
||||
default_md = sha256
|
||||
req_extensions = req_ext
|
||||
distinguished_name = dn
|
||||
|
||||
[ dn ]
|
||||
C = <country>
|
||||
ST = <state>
|
||||
L = <city>
|
||||
O = <organization>
|
||||
OU = <organization unit>
|
||||
CN = <MASTER_IP>
|
||||
|
||||
[ req_ext ]
|
||||
subjectAltName = @alt_names
|
||||
|
||||
[ alt_names ]
|
||||
DNS.1 = kubernetes
|
||||
DNS.2 = kubernetes.default
|
||||
DNS.3 = kubernetes.default.svc
|
||||
DNS.4 = kubernetes.default.svc.cluster
|
||||
DNS.5 = kubernetes.default.svc.cluster.local
|
||||
IP.1 = <MASTER_IP>
|
||||
IP.2 = <MASTER_CLUSTER_IP>
|
||||
|
||||
[ v3_ext ]
|
||||
authorityKeyIdentifier=keyid,issuer:always
|
||||
basicConstraints=CA:FALSE
|
||||
keyUsage=keyEncipherment,dataEncipherment
|
||||
extendedKeyUsage=serverAuth,clientAuth
|
||||
subjectAltName=@alt_names
|
||||
1. 設定ファイルに基づき、証明書署名要求を生成します:
|
||||
|
||||
openssl req -new -key server.key -out server.csr -config csr.conf
|
||||
1. ca.key、ca.crt、server.csrを使用して、サーバー証明書を生成します:
|
||||
|
||||
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
|
||||
-CAcreateserial -out server.crt -days 10000 \
|
||||
-extensions v3_ext -extfile csr.conf
|
||||
1. 証明書署名要求を表示します:
|
||||
|
||||
openssl req -noout -text -in ./server.csr
|
||||
1. 証明書を表示します:
|
||||
|
||||
openssl x509 -noout -text -in ./server.crt
|
||||
|
||||
最後に、同じパラメーターをAPIサーバーのスタートパラメーターに追加します。
|
||||
|
||||
### cfssl
|
||||
|
||||
**cfssl**も証明書生を成するためのツールです。
|
||||
|
||||
1. 以下のように、コマンドラインツールをダウンロードし、解凍して準備してください。
|
||||
なお、サンプルのコマンドは、お使いのハードウェア・アーキテクチャやCFSSLのバージョンに合わせる必要があるかもしれません。
|
||||
|
||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
|
||||
chmod +x cfssl
|
||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
|
||||
chmod +x cfssljson
|
||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
|
||||
chmod +x cfssl-certinfo
|
||||
1. 成果物を格納するディレクトリを作成し、cfsslを初期化します:
|
||||
|
||||
mkdir cert
|
||||
cd cert
|
||||
../cfssl print-defaults config > config.json
|
||||
../cfssl print-defaults csr > csr.json
|
||||
1. CAファイルを生成するためのJSON設定ファイル、例えば`ca-config.json`を作成します:
|
||||
|
||||
{
|
||||
"signing": {
|
||||
"default": {
|
||||
"expiry": "8760h"
|
||||
},
|
||||
"profiles": {
|
||||
"kubernetes": {
|
||||
"usages": [
|
||||
"signing",
|
||||
"key encipherment",
|
||||
"server auth",
|
||||
"client auth"
|
||||
],
|
||||
"expiry": "8760h"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
1. CA証明書署名要求(CSR)用のJSON設定ファイル(例:`ca-csr.json`)を作成します。
|
||||
角括弧で囲まれた値は、必ず使用したい実際の値に置き換えてください。
|
||||
|
||||
{
|
||||
"CN": "kubernetes",
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names":[{
|
||||
"C": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
1. CAキー(`ca-key.pem`)と証明書(`ca.pem`)を生成します:
|
||||
|
||||
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
|
||||
1. APIサーバーの鍵と証明書を生成するためのJSON設定ファイル、例えば`server-csr.json`を作成します。
|
||||
角括弧内の値は、必ず使用したい実際の値に置き換えてください。
|
||||
`MASTER_CLUSTER_IP`は、前のサブセクションで説明したように、APIサーバーのサービスクラスターのIPです。
|
||||
また、以下のサンプルでは、デフォルトのDNSドメイン名として`cluster.local`を使用することを想定しています。
|
||||
|
||||
{
|
||||
"CN": "kubernetes",
|
||||
"hosts": [
|
||||
"127.0.0.1",
|
||||
"<MASTER_IP>",
|
||||
"<MASTER_CLUSTER_IP>",
|
||||
"kubernetes",
|
||||
"kubernetes.default",
|
||||
"kubernetes.default.svc",
|
||||
"kubernetes.default.svc.cluster",
|
||||
"kubernetes.default.svc.cluster.local"
|
||||
],
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names": [{
|
||||
"C": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
1. APIサーバーの鍵と証明書を生成します。
|
||||
デフォルトでは、それぞれ`server-key.pem`と`server.pem`というファイルに保存されます:
|
||||
|
||||
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
|
||||
--config=ca-config.json -profile=kubernetes \
|
||||
server-csr.json | ../cfssljson -bare server
|
||||
|
||||
|
||||
## 自己署名入りCA証明書を配布する
|
||||
|
||||
クライアントノードが自己署名入りCA証明書を有効なものとして認識できない場合があります。
|
||||
|
||||
非プロダクション環境、または会社のファイアウォールの内側での開発環境であれば、自己署名入りCA証明書をすべてのクライアントに配布し、有効な証明書のローカルリストを更新することができます。
|
||||
|
||||
各クライアントで、次の操作を実行します:
|
||||
|
||||
```bash
|
||||
sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
|
||||
sudo update-ca-certificates
|
||||
```
|
||||
|
||||
```
|
||||
Updating certificates in /etc/ssl/certs...
|
||||
1 added, 0 removed; done.
|
||||
Running hooks in /etc/ca-certificates/update.d....
|
||||
done.
|
||||
```
|
||||
|
||||
## 証明書API
|
||||
|
||||
認証に使用するx509証明書のプロビジョニングには`certificates.k8s.io` APIを使用することができます。[ここ](/docs/tasks/tls/managing-tls-in-a-cluster)に記述されています。
|
||||
|
||||
+1
-1
@@ -131,7 +131,7 @@ kubeletはコンテナが問題なく動いていると判断します。
|
||||
|
||||
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ステータスを返します。
|
||||
|
||||
@@ -79,5 +79,5 @@ kubectl delete secret user pass
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [`projected`](/docs/concepts/storage/volumes/#projected)ボリュームについてさらに学ぶ
|
||||
* [all-in-oneボリューム](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)のデザインドキュメントを読む
|
||||
* [all-in-oneボリューム](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)のデザインドキュメントを読む
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ weight: 10
|
||||
* [Cluster DNS](/ja/docs/concepts/services-networking/dns-pod-service/)
|
||||
* [Headless Service](/ja/docs/concepts/services-networking/service/#headless-services)
|
||||
* [PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)
|
||||
* [PersistentVolumeのプロビジョニング](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
|
||||
* [PersistentVolumeのプロビジョニング](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/)
|
||||
* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [kubectl](/docs/reference/kubectl/kubectl/)コマンドラインツール
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ kind: CronJob
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
schedule: "*/1 * * * *"
|
||||
schedule: "* * * * *"
|
||||
jobTemplate:
|
||||
spec:
|
||||
template:
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: volume-test
|
||||
spec:
|
||||
containers:
|
||||
- name: container-test
|
||||
image: busybox
|
||||
volumeMounts:
|
||||
- name: all-in-one
|
||||
mountPath: "/projected-volume"
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: all-in-one
|
||||
projected:
|
||||
sources:
|
||||
- secret:
|
||||
name: mysecret
|
||||
items:
|
||||
- key: username
|
||||
path: my-group/my-username
|
||||
- downwardAPI:
|
||||
items:
|
||||
- path: "labels"
|
||||
fieldRef:
|
||||
fieldPath: metadata.labels
|
||||
- path: "cpu_limit"
|
||||
resourceFieldRef:
|
||||
containerName: container-test
|
||||
resource: limits.cpu
|
||||
- configMap:
|
||||
name: myconfigmap
|
||||
items:
|
||||
- key: config
|
||||
path: my-group/my-config
|
||||
@@ -0,0 +1,27 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: volume-test
|
||||
spec:
|
||||
containers:
|
||||
- name: container-test
|
||||
image: busybox
|
||||
volumeMounts:
|
||||
- name: all-in-one
|
||||
mountPath: "/projected-volume"
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: all-in-one
|
||||
projected:
|
||||
sources:
|
||||
- secret:
|
||||
name: mysecret
|
||||
items:
|
||||
- key: username
|
||||
path: my-group/my-username
|
||||
- secret:
|
||||
name: mysecret2
|
||||
items:
|
||||
- key: password
|
||||
path: my-group/my-password
|
||||
mode: 511
|
||||
@@ -0,0 +1,21 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: sa-token-test
|
||||
spec:
|
||||
containers:
|
||||
- name: container-test
|
||||
image: busybox
|
||||
volumeMounts:
|
||||
- name: token-vol
|
||||
mountPath: "/service-account"
|
||||
readOnly: true
|
||||
serviceAccountName: default
|
||||
volumes:
|
||||
- name: token-vol
|
||||
projected:
|
||||
sources:
|
||||
- serviceAccountToken:
|
||||
audience: api
|
||||
expirationSeconds: 3600
|
||||
path: token
|
||||
@@ -0,0 +1,169 @@
|
||||
---
|
||||
title: Métricas para componentes do sistema Kubernetes
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Métricas dos componentes do sistema podem dar uma visão melhor do que acontece internamente. Métricas são particularmente úteis para construir _dashboards_ e alertas.
|
||||
|
||||
Componentes do Kubernetes emitem métricas no [formato Prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/). Esse formato é um texto simples estruturado, projetado para que pessoas e máquinas possam lê-lo.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Métricas no Kubernetes
|
||||
|
||||
Na maioria dos casos, as métricas estão disponíveis no _endpoint_ `/metrics` do servidor HTTP. Para componentes que não expõem o _endpoint_ por padrão, ele pode ser ativado usando a _flag_ `--bind-address`.
|
||||
|
||||
Exemplos desses componentes:
|
||||
|
||||
- {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
|
||||
- {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
|
||||
- {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
|
||||
- {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
|
||||
- {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
|
||||
|
||||
Em um ambiente de produção, você pode querer configurar o [Servidor Prometheus](https://prometheus.io/) ou algum outro coletor de métricas e disponibilizá-las em algum tipo de banco de dados temporais.
|
||||
|
||||
Observe que o {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} também expõe métricas nos _endpoints_ `/metrics/cadvisor`, `/metrics/resource` e `/metrics/probes`. Essas métricas não possuem o mesmo ciclo de vida.
|
||||
|
||||
Se o seu _cluster_ usa {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, ler as métricas requer autorização por meio de um usuário, grupo ou _ServiceAccount_ com um _ClusterRole_ que conceda o acesso ao `/metrics`.
|
||||
|
||||
Por exemplo:
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: prometheus
|
||||
rules:
|
||||
- nonResourceURLs:
|
||||
- "/metrics"
|
||||
verbs:
|
||||
- get
|
||||
```
|
||||
|
||||
## Ciclo de vida da métrica
|
||||
|
||||
Métrica alfa → Métrica estável → Métrica ultrapassada → Métrica oculta → Métrica excluída
|
||||
|
||||
A métrica alfa não tem garantias de estabilidade. Essas métricas podem ser modificadas ou deletadas a qualquer momento.
|
||||
|
||||
Métricas estáveis possuem a garantia de que não serão alteradas. Isso significa:
|
||||
|
||||
- Uma métrica estável sem uma assinatura ultrapassada não será deletada ou renomeada
|
||||
- O tipo de uma métrica estável não será modificado
|
||||
|
||||
As métricas ultrapassadas estão programadas para exclusão, mas ainda estão disponíveis para uso.
|
||||
Essas métricas incluem uma anotação sobre a versão em que se tornarão ultrapassadas.
|
||||
|
||||
Por exemplo:
|
||||
|
||||
- Antes de se tornar ultrapassado
|
||||
|
||||
```
|
||||
# HELP some_counter isso conta coisas
|
||||
# TYPE some_counter contador
|
||||
some_counter 0
|
||||
```
|
||||
|
||||
- Depois de se tornar ultrapassado
|
||||
|
||||
```
|
||||
# HELP some_counter (obsoleto desde 1.15.0) isso conta coisas
|
||||
# TYPE some_counter contador
|
||||
some_counter 0
|
||||
```
|
||||
|
||||
Métricas ocultas não são mais publicadas para extração, mas ainda estão disponíveis para uso. Para usar uma métrica oculta, por favor consulte a seção [mostrar métricas ocultas](#mostrar-métricas-ocultas).
|
||||
|
||||
Métricas excluídas não estão mais disponíveis e não podem mais ser usadas.
|
||||
|
||||
## Mostrar métricas ocultas
|
||||
|
||||
Como descrito anteriormente, administradores podem habilitar métricas ocultas por meio de uma _flag_ de linha de comando em um binário específico. Isso pode ser usado como uma saída de emergência para os administradores caso percam a migração das métricas ultrapassadas na última versão.
|
||||
|
||||
A _flag_ `show-hidden-metrics-for-version` usa uma versão para a qual você deseja mostrar métricas ultrapassadas nessa versão. A versão é expressada como x.y, onde x é a versão principal e y a versão secundária. A versão de _patch_ não é necessária mesmo que uma métrica possa ser descontinuada em uma versão de _patch_, o motivo é que a política de descontinuação de métricas é executada na versão secundária.
|
||||
|
||||
A _flag_ só pode usar a versão secundária anterior como seu valor. Todas as métricas ocultas no anterior serão emitidas se os administradores definirem a versão anterior como `show-hidden-metrics-for-version`. A versão muito antiga não é permitida porque viola a política de métricas ultrapassadas.
|
||||
|
||||
Utilize a métrica `A` como exemplo, assumindo que `A` está obsoleto em 1.n. De acordo com a política de métricas ultrapassadas, podemos chegar à seguinte conclusão:
|
||||
|
||||
- Na versão `1.n`, a métrica está ultrapassada, e pode ser emitida por padrão.
|
||||
- Na versão `1.n+1`, a métrica está oculta por padrão e pode ser emitida via linha de comando `show-hidden-metrics-for-version=1.n`.
|
||||
- Na versão `1.n+2`, a métrica deve ser removida do código fonte. Não há mais _escape hatch_.
|
||||
|
||||
Se você está atualizando da versão `1.12` para `1.13`, mas ainda depende da métrica `A` ultrapassada em `1.12`, você deve definir métricas ocultas via linha de comando: `--show-hidden-metrics=1.12` e lembre-se de remover essa dependência de métrica antes de atualizar para `1.14`.
|
||||
|
||||
## Desativar métricas do _accelerator_
|
||||
|
||||
O kubelet coleta métricas do _accelerator_ por meio do cAdvisor. Para coletar essas métricas, para _accelerator_ como as GPUs NVIDIA, o kubelet mantinha uma alça aberta no driver. Isso significava que, para realizar alterações na infraestrutura (por exemplo, atualizar o _driver_), um administrador do _cluster_ precisa interromper o agente kubelet.
|
||||
|
||||
A responsabilidade de colear métricas do _accelerator_ agora pertence ao fornecedor, e não ao kubelet. Os fornecedores devem providenciar um contêiner que colete métricas e as exponha ao serviço de métricas (por exemplo, Prometheus).
|
||||
|
||||
O [`DisableAcceleratorUsageMetrics` _feature gate_](/docs/reference/command-line-tools-reference/feature-gates/) desabilita as métricas coletadas pelo kubelet, com uma [_timeline_ para habilitar esse recurso por padrão](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
|
||||
|
||||
## Métricas de componentes
|
||||
|
||||
### Métricas do _kube-controller-manager_
|
||||
|
||||
As métricas do _controller manager_ fornecem informações importantes sobre o desempenho e a integridade do _controller manager_.
|
||||
Essas métricas incluem métricas comuns do agente de execução da linguagem Go, tais como a quantidade de _go_routine_ e métricas específicas do _controller_, como latência de requisições etcd ou latência da _API_ dos provedores de serviços de nuvem (AWS, GCE, OpenStack), que podem ser usadas para medir a integridade de um _cluster_.
|
||||
|
||||
A partir do Kubernetes 1.7, métricas detalhadas de provedores de serviços de nuvem estão disponíveis para operações de armazenamento para o GCE, AWS, Vsphere e OpenStack.
|
||||
Essas métricas podem ser usadas para monitorar a integridade das operações de volumes persistentes.
|
||||
|
||||
Por exemplo, para o GCE as seguintes métricas são chamadas:
|
||||
|
||||
```
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
```
|
||||
|
||||
### Métricas do _kube-scheduler_
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
|
||||
|
||||
O _scheduler_ expõe métricas opcionais que relatam os recursos solicitados e os limites desejados de todos os _pods_ em execução. Essas métricas podem ser usadas para criar _dashboards_ de planejamento de capacidade, avaliar os limites de agendamentos atuais ou históricos, identificar rapidamente cargas de trabalho que não podem ser agendadas devido à falta de recursos e comparar o uso atual com a solicitação do _pod_.
|
||||
|
||||
O _kube-scheduler_ identifica as requisições de [recursos e limites](/docs/concepts/configuration/manage-resources-containers/) configurado para cada _Pod_; quando uma requisição ou limite é diferente de zero o _kube-scheduler_ relata uma _timeseries_ de métricas. Essa _timeseries_ é etiquetada por:
|
||||
|
||||
- _namespace_
|
||||
- nome do _pod_
|
||||
- o nó onde o _pod_ está programado ou uma _string_ vazia caso ainda não esteja programado
|
||||
- prioridade
|
||||
- o _scheduler_ atribuído para esse _pod_
|
||||
- o nome do recurso (por exemplo, `cpu`)
|
||||
- a unidade do recurso, se conhecida (por exemplo, `cores`)
|
||||
|
||||
Uma vez que o _pod_ alcança um estado de conclusão (sua `restartPolicy` está como `Never` ou `onFailure` e está na fase de `Succeeded` ou `Failed`, ou foi deletado e todos os contêineres tem um estado de terminado), a série não é mais relatada já que o _scheduler_ agora está livre para agendar a execução de outros _pods_. As duas métricas são chamadas de `kube_pod_resource_request` e `kube_pod_resource_limit`.
|
||||
|
||||
As métricas são expostas no _endpoint_ HTTP `/metrics/resources` e requerem a mesma autorização que o _endpoint_ `/metrics` no _scheduler_. Você deve usar a _flag_ `--show-hidden-metrics-for-version=1.20` para expor essas métricas de estabilidade alfa.
|
||||
|
||||
## Desativando métricas
|
||||
|
||||
Você pode desativar explicitamente as métricas via linha de comando utilizando a _flag_ `--disabled-metrics`. Isso pode ser desejado se, por exemplo, uma métrica estiver causando um problema de desempenho. A entrada é uma lista de métricas desabilitadas (ou seja, `--disabled-metrics=metric1,metric2`).
|
||||
|
||||
## Aplicação de cardinalidade de métrica
|
||||
|
||||
As métricas com dimensões sem limites podem causar problemas de memória nos componentes que elas instrumentam. Para limitar a utilização de recursos você pode usar a opção de linha de comando `--allow-label-value` para dinamicamente configurar uma lista de permissões de valores de _label_ para uma métrica.
|
||||
|
||||
No estágio alfa, a _flag_ pode receber apenas uma série de mapeamentos como lista de permissões de _labels_ para uma métrica.
|
||||
Cada mapeamento tem o formato `<metric_name>,<label_name>=<allowed_labels>` onde `<allowed_labels>` é uma lista separada por vírgulas de nomes aceitáveis para a _label_.
|
||||
|
||||
O formato geral se parece com:
|
||||
`--allow-label-value <metric_name>,<label_name>='<allow_value1>, <allow_value2>...', <metric_name2>,<label_name>='<allow_value1>, <allow_value2>...', ...`.
|
||||
|
||||
Por exemplo:
|
||||
`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'`
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- Leia sobre o [formato de texto do Prometheus](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) para métricas
|
||||
- Veja a lista de [métricas estáveis do Kubernetes](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
|
||||
- Leia sobre a [Política de suspensão de uso do Kubernetes](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
|
||||
@@ -3,7 +3,7 @@ kind: CronJob
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
schedule: "*/1 * * * *"
|
||||
schedule: "* * * * *"
|
||||
jobTemplate:
|
||||
spec:
|
||||
template:
|
||||
|
||||
@@ -0,0 +1,361 @@
|
||||
---
|
||||
title: 垃圾收集
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Garbage Collection
|
||||
content_type: concept
|
||||
weight: 50
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
{{<glossary_definition term_id="garbage-collection" length="short">}} This
|
||||
allows the clean up of resources like the following:
|
||||
-->
|
||||
{{<glossary_definition term_id="garbage-collection" length="short">}}
|
||||
垃圾收集允许系统清理如下资源：
|
||||
|
||||
<!--
|
||||
* [Failed pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
|
||||
* [Completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
* [Objects without owner references](#owners-dependents)
|
||||
* [Unused containers and container images](#containers-images)
|
||||
* [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete)
|
||||
* [Stale or expired CertificateSigningRequests (CSRs)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
|
||||
* {{<glossary_tooltip text="Nodes" term_id="node">}} deleted in the following scenarios:
|
||||
* On a cloud when the cluster uses a [cloud controller manager](/docs/concepts/architecture/cloud-controller/)
|
||||
* On-premises when the cluster uses an addon similar to a cloud controller
|
||||
manager
|
||||
* [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats)
|
||||
-->
|
||||
* [失败的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
|
||||
* [已完成的 Job](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
* [不再存在属主引用的对象](#owners-dependents)
|
||||
* [未使用的容器和容器镜像](#containers-images)
|
||||
* [动态制备的、StorageClass 回收策略为 Delete 的 PV 卷](/zh/docs/concepts/storage/persistent-volumes/#delete)
|
||||
* [阻滞或者过期的 CertificateSigningRequest (CSRs)](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
|
||||
* 在以下情形中删除了的{{<glossary_tooltip text="节点" term_id="node">}}对象：
|
||||
* 当集群使用[云控制器管理器](/zh/docs/concepts/architecture/cloud-controller/)运行于云端时；
|
||||
* 当集群使用类似于云控制器管理器的插件运行在本地环境中时。
|
||||
* [节点租约对象](/zh/docs/concepts/architecture/nodes/#heartbeats)
|
||||
|
||||
<!--
|
||||
## Owners and dependents {#owners-dependents}
|
||||
|
||||
Many objects in Kubernetes link to each other through [*owner references*](/docs/concepts/overview/working-with-objects/owners-dependents/).
|
||||
Owner references tell the control plane which objects are dependent on others.
|
||||
Kubernetes uses owner references to give the control plane, and other API
|
||||
clients, the opportunity to clean up related resources before deleting an
|
||||
object. In most cases, Kubernetes manages owner references automatically.
|
||||
-->
|
||||
## 属主与依赖 {#owners-dependents}
|
||||
|
||||
Kubernetes 中很多对象通过[*属主引用*](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)
|
||||
链接到彼此。属主引用（Owner Reference）可以告诉控制面哪些对象依赖于其他对象。
|
||||
Kubernetes 使用属主引用来为控制面以及其他 API 客户端在删除某对象时提供一个
|
||||
清理关联资源的机会。在大多数场合，Kubernetes 都是自动管理属主引用的。
|
||||
|
||||
<!--
|
||||
Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/)
|
||||
mechanism that some resources also use. For example, consider a
|
||||
{{<glossary_tooltip text="Service" term_id="service">}} that creates
|
||||
`EndpointSlice` objects. The Service uses *labels* to allow the control plane to
|
||||
determine which `EndpointSlice` objects are used for that Service. In addition
|
||||
to the labels, each `EndpointSlice` that is managed on behalf of a Service has
|
||||
an owner reference. Owner references help different parts of Kubernetes avoid
|
||||
interfering with objects they don’t control.
|
||||
-->
|
||||
属主关系与某些资源所使用的的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)
|
||||
不同。例如，考虑一个创建 `EndpointSlice` 对象的 {{<glossary_tooltip text="Service" term_id="service">}}
|
||||
对象。Service 对象使用*标签*来允许控制面确定哪些 `EndpointSlice` 对象被该
|
||||
Service 使用。除了标签，每个被 Service 托管的 `EndpointSlice` 对象还有一个属主引用属性。
|
||||
属主引用可以帮助 Kubernetes 中的不同组件避免干预并非由它们控制的对象。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Cross-namespace owner references are disallowed by design.
|
||||
Namespaced dependents can specify cluster-scoped or namespaced owners.
|
||||
A namespaced owner **must** exist in the same namespace as the dependent.
|
||||
If it does not, the owner reference is treated as absent, and the dependent
|
||||
is subject to deletion once all owners are verified absent.
|
||||
-->
|
||||
根据设计，系统不允许出现跨名字空间的属主引用。名字空间作用域的依赖对象可以指定集群作用域或者名字空间作用域的属主。
|
||||
名字空间作用域的属主**必须**存在于依赖对象所在的同一名字空间。
|
||||
如果属主位于不同名字空间，则属主引用被视为不存在，而当检查发现所有属主都已不存在时，
|
||||
依赖对象会被删除。
|
||||
|
||||
<!--
|
||||
Cluster-scoped dependents can only specify cluster-scoped owners.
|
||||
In v1.20+, if a cluster-scoped dependent specifies a namespaced kind as an owner,
|
||||
it is treated as having an unresolvable owner reference, and is not able to be garbage collected.
|
||||
-->
|
||||
集群作用域的依赖对象只能指定集群作用域的属主。
|
||||
在 1.20 及更高版本中，如果一个集群作用域的依赖对象指定了某个名字空间作用域的类别作为其属主，
|
||||
则该对象被视为拥有一个无法解析的属主引用，因而无法被垃圾收集处理。
|
||||
|
||||
<!--
|
||||
In v1.20+, if the garbage collector detects an invalid cross-namespace `ownerReference`,
|
||||
or a cluster-scoped dependent with an `ownerReference` referencing a namespaced kind, a warning Event
|
||||
with a reason of `OwnerRefInvalidNamespace` and an `involvedObject` of the invalid dependent is reported.
|
||||
You can check for that kind of Event by running
|
||||
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`.
|
||||
-->
|
||||
在 1.20 及更高版本中，如果垃圾收集器检测到非法的跨名字空间 `ownerReference`，
|
||||
或者某集群作用域的依赖对象的 `ownerReference` 引用某名字空间作用域的类别，
|
||||
系统会生成一个警告事件，其原因为 `OwnerRefInvalidNamespace`，`involvedObject`
|
||||
设置为非法的依赖对象。你可以通过运行
|
||||
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`
|
||||
来检查是否存在这类事件。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Cascading deletion {#cascading-deletion}
|
||||
|
||||
Kubernetes checks for and deletes objects that no longer have owner
|
||||
references, like the pods left behind when you delete a ReplicaSet. When you
|
||||
delete an object, you can control whether Kubernetes deletes the object's
|
||||
dependents automatically, in a process called *cascading deletion*. There are
|
||||
two types of cascading deletion, as follows:
|
||||
|
||||
* Foreground cascading deletion
|
||||
* Background cascading deletion
|
||||
-->
|
||||
## 级联删除 {#cascading-deletion}
|
||||
|
||||
Kubernetes 会检查并删除那些不再拥有属主引用的对象，例如在你删除了 ReplicaSet
|
||||
之后留下来的 Pod。当你删除某个对象时，你可以控制 Kubernetes 是否要通过一个称作
|
||||
级联删除（Cascading Deletion）的过程自动删除该对象的依赖对象。
|
||||
级联删除有两种类型，分别如下：
|
||||
|
||||
* 前台级联删除
|
||||
* 后台级联删除
|
||||
|
||||
<!--
|
||||
You can also control how and when garbage collection deletes resources that have
|
||||
owner references using Kubernetes {{<glossary_tooltip text="finalizers" term_id="finalizer">}}.
|
||||
-->
|
||||
你也可以使用 Kubernetes {{<glossary_tooltip text="Finalizers" term_id="finalizer">}}
|
||||
来控制垃圾收集机制如何以及何时删除包含属主引用的资源。
|
||||
|
||||
<!--
|
||||
### Foreground cascading deletion {#foreground-deletion}
|
||||
|
||||
In foreground cascading deletion, the owner object you're deleting first enters
|
||||
a *deletion in progress* state. In this state, the following happens to the
|
||||
owner object:
|
||||
-->
|
||||
### 前台级联删除 {#foreground-deletion}
|
||||
|
||||
在前台级联删除中，正在被你删除的对象首先进入 *deletion in progress* 状态。
|
||||
在这种状态下，针对属主对象会发生以下事情：
|
||||
|
||||
<!--
|
||||
* The Kubernetes API server sets the object's `metadata.deletionTimestamp`
|
||||
field to the time the object was marked for deletion.
|
||||
* The Kubernetes API server also sets the `metadata.finalizers` field to
|
||||
`foregroundDeletion`.
|
||||
* The object remains visible through the Kubernetes API until the deletion
|
||||
process is complete.
|
||||
-->
|
||||
* Kubernetes API 服务器将对象的 `metadata.deletionTimestamp`
|
||||
字段设置为对象被标记为要删除的时间点。
|
||||
* Kubernetes API 服务器也会将 `metadata.finalizers` 字段设置为 `foregroundDeletion`。
|
||||
* 在删除过程完成之前，通过 Kubernetes API 仍然可以看到该对象。
|
||||
|
||||
<!--
|
||||
After the owner object enters the deletion in progress state, the controller
|
||||
deletes the dependents. After deleting all the dependent objects, the controller
|
||||
deletes the owner object. At this point, the object is no longer visible in the
|
||||
Kubernetes API.
|
||||
|
||||
During foreground cascading deletion, the only dependents that block owner
|
||||
deletion are those that have the `ownerReference.blockOwnerDeletion=true` field.
|
||||
See [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)
|
||||
to learn more.
|
||||
-->
|
||||
当属主对象进入删除过程中状态后，控制器删除其依赖对象。控制器在删除完所有依赖对象之后，
|
||||
删除属主对象。这时，通过 Kubernetes API 就无法再看到该对象。
|
||||
|
||||
在前台级联删除过程中，唯一的可能阻止属主对象被删除的依赖对象是那些带有
|
||||
`ownerReference.blockOwnerDeletion=true` 字段的对象。
|
||||
参阅[使用前台级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)
|
||||
以了解进一步的细节。
|
||||
|
||||
<!--
|
||||
### Background cascading deletion {#background-deletion}
|
||||
|
||||
In background cascading deletion, the Kubernetes API server deletes the owner
|
||||
object immediately and the controller cleans up the dependent objects in
|
||||
the background. By default, Kubernetes uses background cascading deletion unless
|
||||
you manually use foreground deletion or choose to orphan the dependent objects.
|
||||
|
||||
See [Use background cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)
|
||||
to learn more.
|
||||
-->
|
||||
### 后台级联删除 {#background-deletion}
|
||||
|
||||
在后台级联删除过程中，Kubernetes 服务器立即删除属主对象，控制器在后台清理所有依赖对象。
|
||||
默认情况下，Kubernetes 使用后台级联删除方案，除非你手动设置了要使用前台删除，
|
||||
或者选择遗弃依赖对象。
|
||||
|
||||
参阅[使用后台级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)
|
||||
以了解进一步的细节。
|
||||
|
||||
<!--
|
||||
### Orphaned dependents
|
||||
|
||||
When Kubernetes deletes an owner object, the dependents left behind are called
|
||||
*orphan* objects. By default, Kubernetes deletes dependent objects. To learn how
|
||||
to override this behaviour, see [Delete owner objects and orphan dependents](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
|
||||
-->
|
||||
### 被遗弃的依赖对象 {#orphaned-dependents}
|
||||
|
||||
当 Kubernetes 删除某个属主对象时，被留下来的依赖对象被称作被遗弃的（Orphaned）对象。
|
||||
默认情况下，Kubernetes 会删除依赖对象。要了解如何重载这种默认行为，可参阅
|
||||
[删除属主对象和遗弃依赖对象](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)。
|
||||
|
||||
<!--
|
||||
## Garbage collection of unused containers and images {#containers-images}
|
||||
|
||||
The {{<glossary_tooltip text="kubelet" term_id="kubelet">}} performs garbage
|
||||
collection on unused images every five minutes and on unused containers every
|
||||
minute. You should avoid using external garbage collection tools, as these can
|
||||
break the kubelet behavior and remove containers that should exist.
|
||||
-->
|
||||
## 未使用容器和镜像的垃圾收集 {#containers-images}
|
||||
|
||||
{{<glossary_tooltip text="kubelet" term_id="kubelet">}} 会每五分钟对未使用的镜像执行一次垃圾收集，
|
||||
每分钟对未使用的容器执行一次垃圾收集。
|
||||
你应该避免使用外部的垃圾收集工具，因为外部工具可能会破坏 kubelet
|
||||
的行为，移除应该保留的容器。
|
||||
|
||||
<!--
|
||||
To configure options for unused container and image garbage collection, tune the
|
||||
kubelet using a [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/)
|
||||
and change the parameters related to garbage collection using the
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
resource type.
|
||||
-->
|
||||
要配置对未使用容器和镜像的垃圾收集选项，可以使用一个
|
||||
[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)，基于
|
||||
[`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
资源类型来调整与垃圾搜集相关的 kubelet 行为。
|
||||
|
||||
<!--
|
||||
### Container image lifecycle
|
||||
|
||||
Kubernetes manages the lifecycle of all images through its *image manager*,
|
||||
which is part of the kubelet, with the cooperation of
|
||||
{{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}. The kubelet
|
||||
considers the following disk usage limits when making garbage collection
|
||||
decisions:
|
||||
-->
|
||||
### 容器镜像生命期 {#container-image-lifecycle}
|
||||
|
||||
Kubernetes 通过其镜像管理器（Image Manager）来管理所有镜像的生命周期，
|
||||
该管理器是 kubelet 的一部分，工作时与
|
||||
{{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}} 协同。
|
||||
kubelet 在作出垃圾收集决定时会考虑如下磁盘用量约束：
|
||||
|
||||
* `HighThresholdPercent`
|
||||
* `LowThresholdPercent`
|
||||
|
||||
<!--
|
||||
Disk usage above the configured `HighThresholdPercent` value triggers garbage
|
||||
collection, which deletes images in order based on the last time they were used,
|
||||
starting with the oldest first. The kubelet deletes images
|
||||
until disk usage reaches the `LowThresholdPercent` value.
|
||||
-->
|
||||
磁盘用量超出所配置的 `HighThresholdPercent` 值时会触发垃圾收集，
|
||||
垃圾收集器会基于镜像上次被使用的时间来按顺序删除它们，首先删除的是最老的镜像。
|
||||
kubelet 会持续删除镜像，直到磁盘用量到达 `LowThresholdPercent` 值为止。
|
||||
|
||||
<!--
|
||||
### Container garbage collection {#container-image-garbage-collection}
|
||||
|
||||
The kubelet garbage collects unused containers based on the following variables,
|
||||
which you can define:
|
||||
-->
|
||||
### 容器垃圾收集 {#container-image-garbage-collection}
|
||||
|
||||
kubelet 会基于如下变量对所有未使用的容器执行垃圾收集操作，这些变量都是你可以定义的：
|
||||
|
||||
<!--
|
||||
* `MinAge`: the minimum age at which the kubelet can garbage collect a
|
||||
container. Disable by setting to `0`.
|
||||
* `MaxPerPodContainer`: the maximum number of dead containers each Pod pair
|
||||
can have. Disable by setting to less than `0`.
|
||||
* `MaxContainers`: the maximum number of dead containers the cluster can have.
|
||||
Disable by setting to less than `0`.
|
||||
-->
|
||||
* `MinAge`：kubelet 可以垃圾回收某个容器时该容器的最小年龄。设置为 `0`
|
||||
表示禁止使用此规则。
|
||||
* `MaxPerPodContainer`：每个 Pod 可以包含的已死亡的容器个数上限。设置为小于 `0`
|
||||
的值表示禁止使用此规则。
|
||||
* `MaxContainers`：集群中可以存在的已死亡的容器个数上限。设置为小于 `0`
|
||||
的值意味着禁止应用此规则。
|
||||
|
||||
<!--
|
||||
In addition to these variables, the kubelet garbage collects unidentified and
|
||||
deleted containers, typically starting with the oldest first.
|
||||
|
||||
`MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other
|
||||
in situations where retaining the maximum number of containers per Pod
|
||||
(`MaxPerPodContainer`) would go outside the allowable total of global dead
|
||||
containers (`MaxContainers`). In this situation, the kubelet adjusts
|
||||
`MaxPerPodContainer` to address the conflict. A worst-case scenario would be to
|
||||
downgrade `MaxPerPodContainer` to `1` and evict the oldest containers.
|
||||
Additionally, containers owned by pods that have been deleted are removed once
|
||||
they are older than `MinAge`.
|
||||
-->
|
||||
除以上变量之外，kubelet 还会垃圾收集除无标识的以及已删除的容器，通常从最老的容器开始。
|
||||
|
||||
当保持每个 Pod 的最大数量的容器（`MaxPerPodContainer`）会使得全局的已死亡容器个数超出上限
|
||||
（`MaxContainers`）时，`MaxPerPodContainer` 和 `MaxContainers` 之间可能会出现冲突。
|
||||
在这种情况下，kubelet 会调整 `MaxPerPodContainer` 来解决这一冲突。
|
||||
最坏的情形是将 `MaxPerPodContainer` 降格为 `1`，并驱逐最老的容器。
|
||||
此外，当隶属于某已被删除的 Pod 的容器的年龄超过 `MinAge` 时，它们也会被删除。
|
||||
|
||||
{{<note>}}
|
||||
<!--
|
||||
The kubelet only garbage collects the containers it manages.
|
||||
-->
|
||||
kubelet 仅会回收由它所管理的容器。
|
||||
{{</note>}}
|
||||
|
||||
<!--
|
||||
## Configuring garbage collection {#configuring-gc}
|
||||
|
||||
You can tune garbage collection of resources by configuring options specific to
|
||||
the controllers managing those resources. The following pages show you how to
|
||||
configure garbage collection:
|
||||
|
||||
* [Configuring cascading deletion of Kubernetes objects](/docs/tasks/administer-cluster/use-cascading-deletion/)
|
||||
* [Configuring cleanup of finished Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
-->
|
||||
## 配置垃圾收集 {#configuring-gc}
|
||||
|
||||
你可以通过配置特定于管理资源的控制器来调整资源的垃圾收集行为。
|
||||
下面的页面为你展示如何配置垃圾收集：
|
||||
|
||||
* [配置 Kubernetes 对象的级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/)
|
||||
* [配置已完成 Job 的清理](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
|
||||
<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn more about [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/).
|
||||
* Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
|
||||
* Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs.
|
||||
-->
|
||||
* 进一步了解 [Kubernetes 对象的属主关系](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)。
|
||||
* 进一步了解 Kubernetes [finalizers](/zh/docs/concepts/overview/working-with-objects/finalizers/)。
|
||||
* 进一步了解 [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) (beta)，
|
||||
该控制器负责清理已完成的 Job。
|
||||
|
||||
@@ -128,7 +128,7 @@ For example:
|
||||
<!--
|
||||
* After deprecation
|
||||
-->
|
||||
* 被启用之后：
|
||||
* 被弃用之后：
|
||||
|
||||
```
|
||||
# HELP some_counter (Deprecated since 1.15.0) this counts things
|
||||
|
||||
@@ -47,7 +47,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 to is routed
|
||||
(favoring topologically closer endpoints).
|
||||
-->
|
||||
Kubernetes 集群越来越多的部署到多区域环境中。
|
||||
|
||||
@@ -107,7 +107,7 @@ created anew.
|
||||
如果 Pod 因为任何原因被删除，甚至某完全相同的替代 Pod 被创建时，
|
||||
这个相关的对象（例如这里的卷）也会被删除并重建。
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" title="Pod 结构图例" width="50%" >}}
|
||||
{{< figure src="/images/docs/pod.svg" title="Pod 结构图例" class="diagram-medium" >}}
|
||||
|
||||
*一个包含多个容器的 Pod 中包含一个用来拉取文件的程序和一个 Web 服务器，
|
||||
均使用持久卷作为容器间共享的存储。*
|
||||
@@ -153,7 +153,7 @@ Value | Description
|
||||
-->
|
||||
取值 | 描述
|
||||
:-----|:-----------
|
||||
`Pending`（悬决）| Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间，
|
||||
`Pending`（悬决）| Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
|
||||
`Running`（运行中） | Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
|
||||
`Succeeded`（成功） | Pod 中的所有容器都已成功终止，并且不会再重启。
|
||||
`Failed`（失败） | Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。
|
||||
@@ -300,14 +300,14 @@ Pod 有一个 PodStatus 对象，其中包含一个
|
||||
* `PodScheduled`: the Pod has been scheduled to a node.
|
||||
* `ContainersReady`: all containers in the Pod are ready.
|
||||
* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
|
||||
have started successfully.
|
||||
have completed successfully.
|
||||
* `Ready`: the Pod is able to serve requests and should be added to the load
|
||||
balancing pools of all matching Services.
|
||||
-->
|
||||
* `PodScheduled`：Pod 已经被调度到某节点；
|
||||
* `ContainersReady`：Pod 中所有容器都已就绪；
|
||||
* `Initialized`：所有的 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)
|
||||
都已成功启动；
|
||||
都已成功完成；
|
||||
* `Ready`：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。
|
||||
|
||||
<!--
|
||||
@@ -425,93 +425,145 @@ When a Pod's containers are Ready but at least one custom condition is missing o
|
||||
<!--
|
||||
## Container probes
|
||||
|
||||
A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
|
||||
A _probe_ is a diagnostic
|
||||
performed periodically by the
|
||||
[kubelet](/docs/reference/command-line-tools-reference/kubelet/)
|
||||
on a Container. To perform a diagnostic,
|
||||
the kubelet calls a
|
||||
[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
|
||||
the container. There are three types of handlers:
|
||||
on a container. To perform a diagnostic,
|
||||
the kubelet either executes code within the container, or makes
|
||||
a network request.
|
||||
-->
|
||||
## 容器探针 {#container-probes}
|
||||
|
||||
[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
|
||||
是由 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
|
||||
要执行诊断，kubelet 调用由容器实现的
|
||||
[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)
|
||||
（处理程序）。有三种类型的处理程序：
|
||||
probe 是由 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
|
||||
要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。
|
||||
|
||||
<!--
|
||||
* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
|
||||
Executes a specified command inside the container. The diagnostic
|
||||
### Check mechanisms {#probe-check-methods}
|
||||
|
||||
There are four different ways to check a container using a probe.
|
||||
Each probe must define exactly one of these four mechanisms:
|
||||
|
||||
`exec`
|
||||
: Executes a specified command inside the container. The diagnostic
|
||||
is considered successful if the command exits with a status code of 0.
|
||||
|
||||
* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
|
||||
Performs a TCP check against the Pod's IP address on
|
||||
a specified port. The diagnostic is considered successful if the port is open.
|
||||
`grpc`
|
||||
: Performs a remote procedure call using [gRPC](https://grpc.io/).
|
||||
The target should implement
|
||||
[gRPC health checks](https://grpc.io/grpc/core/md_doc_health-checking.html).
|
||||
The diagnostic is considered successful if the `status`
|
||||
of the response is `SERVING`.
|
||||
gRPC probes are an alpha feature and are only available if you
|
||||
enable the `GRPCContainerProbe`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
|
||||
|
||||
`httpGet`
|
||||
: Performs an HTTP `GET` request against the Pod's IP
|
||||
address on a specified port and path. The diagnostic is
|
||||
considered successful if the response has a status code
|
||||
greater than or equal to 200 and less than 400.
|
||||
|
||||
`tcpSocket`
|
||||
: Performs a TCP check against the Pod's IP address on
|
||||
a specified port. The diagnostic is considered successful if
|
||||
the port is open. If the remote system (the container) closes
|
||||
the connection immediately after it opens, this counts as healthy.
|
||||
|
||||
* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
|
||||
Performs an HTTP `GET` request against the Pod's IP
|
||||
address on a specified port and path. The diagnostic is considered successful
|
||||
if the response has a status code greater than or equal to 200 and less than 400.
|
||||
-->
|
||||
- [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core)：
|
||||
在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
|
||||
### 检查机制 {#probe-check-methods}
|
||||
|
||||
- [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core)：
|
||||
对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。
|
||||
使用探针来检查容器有四种不同的方法。
|
||||
每个探针都必须准确定义为这四种机制中的一种：
|
||||
|
||||
- [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)：
|
||||
对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200
|
||||
`exec`
|
||||
: 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
|
||||
|
||||
`grpc`
|
||||
: 使用 [gRPC](https://grpc.io/) 执行一个远程过程调用。
|
||||
目标应该实现
|
||||
[gRPC健康检查](https://grpc.io/grpc/core/md_doc_health-checking.html)。
|
||||
如果响应的状态是 "SERVING"，则认为诊断成功。
|
||||
gRPC 探针是一个 alpha 特性，只有在你启用了
|
||||
"GRPCContainerProbe" [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gate/)时才能使用。
|
||||
|
||||
`httpGet`
|
||||
: 对容器的 IP 地址上指定端口和路径执行 HTTP `GET` 请求。如果响应的状态码大于等于 200
|
||||
且小于 400，则诊断被认为是成功的。
|
||||
|
||||
`tcpSocket`
|
||||
: 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。
|
||||
如果远程系统（容器）在打开连接后立即将其关闭，这算作是健康的。
|
||||
|
||||
<!--
|
||||
### Probe outcome
|
||||
Each probe has one of three results:
|
||||
|
||||
* `Success`: The container passed the diagnostic.
|
||||
* `Failure`: The container failed the diagnostic.
|
||||
* `Unknown`: The diagnostic failed, so no action should be taken.
|
||||
`Success`
|
||||
: The container passed the diagnostic.
|
||||
|
||||
`Failure`
|
||||
: The container failed the diagnostic.
|
||||
|
||||
`Unknown`
|
||||
: The diagnostic failed (no action should be taken, and the kubelet
|
||||
will make further checks).
|
||||
|
||||
-->
|
||||
### 探测结果 {#probe-outcome}
|
||||
每次探测都将获得以下三种结果之一：
|
||||
|
||||
- `Success`（成功）：容器通过了诊断。
|
||||
- `Failure`（失败）：容器未通过诊断。
|
||||
- `Unknown`（未知）：诊断失败，因此不会采取任何行动。
|
||||
`Success`（成功）
|
||||
: 容器通过了诊断。
|
||||
|
||||
`Failure`（失败）
|
||||
: 容器未通过诊断。
|
||||
|
||||
`Unknown`（未知）
|
||||
: 诊断失败，因此不会采取任何行动。
|
||||
|
||||
<!--
|
||||
### Types of probe
|
||||
The kubelet can optionally perform and react to three kinds of probes on running
|
||||
containers:
|
||||
-->
|
||||
### 探测类型 {#types-of-probe}
|
||||
针对运行中的容器，`kubelet` 可以选择是否执行以下三种探针，以及如何针对探测结果作出反应：
|
||||
|
||||
<!--
|
||||
* `livenessProbe`: Indicates whether the container is running. If
|
||||
the liveness probe fails, the kubelet kills the container, and the container
|
||||
is subjected to its [restart policy](#restart-policy). If a Container does not
|
||||
provide a liveness probe, the default state is `Success`.
|
||||
`livenessProbe`
|
||||
: Indicates whether the container is running. If
|
||||
the liveness probe fails, the kubelet kills the container, and the container
|
||||
is subjected to its [restart policy](#restart-policy). If a container does not
|
||||
provide a liveness probe, the default state is `Success`.
|
||||
|
||||
* `readinessProbe`: Indicates whether the container is ready to respond to requests.
|
||||
If the readiness probe fails, the endpoints controller removes the Pod's IP
|
||||
address from the endpoints of all Services that match the Pod. The default
|
||||
state of readiness before the initial delay is `Failure`. If a Container does
|
||||
not provide a readiness probe, the default state is `Success`.
|
||||
`readinessProbe`
|
||||
: Indicates whether the container is ready to respond to requests.
|
||||
If the readiness probe fails, the endpoints controller removes the Pod's IP
|
||||
address from the endpoints of all Services that match the Pod. The default
|
||||
state of readiness before the initial delay is `Failure`. If a container does
|
||||
not provide a readiness probe, the default state is `Success`.
|
||||
|
||||
* `startupProbe`: Indicates whether the application within the container is started.
|
||||
All other probes are disabled if a startup probe is provided, until it succeeds.
|
||||
If the startup probe fails, the kubelet kills the container, and the container
|
||||
is subjected to its [restart policy](#restart-policy). If a Container does not
|
||||
provide a startup probe, the default state is `Success`.
|
||||
`startupProbe`
|
||||
: Indicates whether the application within the container is started.
|
||||
All other probes are disabled if a startup probe is provided, until it succeeds.
|
||||
If the startup probe fails, the kubelet kills the container, and the container
|
||||
is subjected to its [restart policy](#restart-policy). If a container does not
|
||||
provide a startup probe, the default state is `Success`.
|
||||
-->
|
||||
- `livenessProbe`：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器，
|
||||
|
||||
`livenessProbe`
|
||||
: 指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器，
|
||||
并且容器将根据其[重启策略](#restart-policy)决定未来。如果容器不提供存活探针，
|
||||
则默认状态为 `Success`。
|
||||
|
||||
- `readinessProbe`：指示容器是否准备好为请求提供服务。如果就绪态探测失败，
|
||||
`readinessProbe`
|
||||
: 指示容器是否准备好为请求提供服务。如果就绪态探测失败，
|
||||
端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。
|
||||
初始延迟之前的就绪态的状态值默认为 `Failure`。
|
||||
如果容器不提供就绪态探针，则默认状态为 `Success`。
|
||||
|
||||
- `startupProbe`: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被
|
||||
`startupProbe`
|
||||
: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被
|
||||
禁用，直到此探针成功为止。如果启动探测失败，`kubelet` 将杀死容器，而容器依其
|
||||
[重启策略](#restart-policy)进行重启。
|
||||
如果容器没有提供启动探测，则默认状态为 `Success`。
|
||||
@@ -524,9 +576,9 @@ see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod
|
||||
[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
|
||||
|
||||
<!--
|
||||
### When should you use a liveness probe?
|
||||
#### When should you use a liveness probe?
|
||||
-->
|
||||
### 何时该使用存活态探针? {#when-should-you-use-a-liveness-probe}
|
||||
#### 何时该使用存活态探针? {#when-should-you-use-a-liveness-probe}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
|
||||
|
||||
@@ -546,9 +598,9 @@ specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
|
||||
并指定`restartPolicy` 为 "`Always`" 或 "`OnFailure`"。
|
||||
|
||||
<!--
|
||||
### When should you use a readiness probe?
|
||||
#### When should you use a readiness probe?
|
||||
-->
|
||||
### 何时该使用就绪态探针? {#when-should-you-use-a-readiness-probe}
|
||||
#### 何时该使用就绪态探针? {#when-should-you-use-a-readiness-probe}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
|
||||
|
||||
@@ -606,9 +658,9 @@ to stop.
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### When should you use a startup probe?
|
||||
#### When should you use a startup probe?
|
||||
-->
|
||||
### 何时该使用启动探针？ {#when-should-you-use-a-startup-probe}
|
||||
#### 何时该使用启动探针？ {#when-should-you-use-a-startup-probe}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
@@ -852,21 +904,20 @@ This avoids a resource leak as Pods are created and terminated over time.
|
||||
|
||||
<!--
|
||||
* Get hands-on experience
|
||||
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
[attaching handlers to container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
|
||||
* Get hands-on experience
|
||||
[configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
|
||||
|
||||
* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
|
||||
|
||||
* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
|
||||
and
|
||||
[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
|
||||
* For detailed information about Pod and container status in the API, see
|
||||
the API reference documentation covering
|
||||
[`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.
|
||||
-->
|
||||
* 动手实践[为容器生命周期时间关联处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
|
||||
* 动手实践[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
|
||||
* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。
|
||||
* 关于 API 中定义的有关 Pod/容器的详细规范信息，
|
||||
可参阅 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
|
||||
和 [ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)。
|
||||
* 关于 API 中定义的有关 Pod 和容器状态的详细规范信息，
|
||||
可参阅 API 参考文档中 Pod 的 [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) 字段。
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 访问 API
|
||||
title: API 访问控制
|
||||
weight: 15
|
||||
no_list: true
|
||||
---
|
||||
|
||||
@@ -1813,8 +1813,8 @@ webhooks:
|
||||
<!--
|
||||
Admission webhooks created using `admissionregistration.k8s.io/v1` default `failurePolicy` to `Fail`.
|
||||
-->
|
||||
使用 `admissionregistration.k8s.io/v1beta1` 创建的准入 Webhook 将
|
||||
`failurePolicy` 默认设置为 `Ignore`。
|
||||
使用 `admissionregistration.k8s.io/v1` 创建的准入 Webhook 将
|
||||
`failurePolicy` 默认设置为 `Fail`。
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="admissionregistration.k8s.io/v1beta1" %}}
|
||||
|
||||
@@ -2079,11 +2079,11 @@ are running with no RBAC denial messages in the server logs, you can remove the
|
||||
在服务器日志中没有出现 RBAC 拒绝消息，就可以删除 ABAC 鉴权器。
|
||||
|
||||
<!--
|
||||
## Permissive RBAC Permissions
|
||||
### Permissive RBAC Permissions
|
||||
|
||||
You can replicate a permissive policy using RBAC role bindings.
|
||||
-->
|
||||
## 宽松的 RBAC 权限 {#permissive-rbac-permissions}
|
||||
### 宽松的 RBAC 权限 {#permissive-rbac-permissions}
|
||||
|
||||
你可以使用 RBAC 角色绑定在多个场合使用宽松的策略。
|
||||
|
||||
|
||||
@@ -29,6 +29,8 @@ tags:
|
||||
控制平面（Control Plane）是指容器编排层，它暴露 API 和接口来定义、
|
||||
部署容器和管理容器的生命周期。
|
||||
|
||||
<!--more-->
|
||||
|
||||
<!--
|
||||
This layer is composed by many different components, such as (but not restricted to):
|
||||
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 节点参考信息
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Node Reference Information
|
||||
weight: 40
|
||||
-->
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
title: 关于 dockershim 移除和使用兼容 CRI 运行时的外部文章
|
||||
content_type: reference
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
title: External Articles on dockershim Removal and on Using CRI-compatible Runtimes
|
||||
content_type: reference
|
||||
weight: 20
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This is a list of articles about:
|
||||
|
||||
- the Kubernetes' deprecation and removal of _dockershim_
|
||||
- using CRI-compatible container runtimes
|
||||
-->
|
||||
这是有关以下内容的文章列表：
|
||||
|
||||
- Kubernetes 弃用和删除 _dockershim_
|
||||
- 使用兼容 CRI 的容器运行时
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Primary sources
|
||||
|
||||
* [Kubernetes Blog: "Dockershim Deprecation FAQ", 2020/12/02](/blog/2020/12/02/dockershim-faq/)
|
||||
|
||||
* [Kubernetes Documentation: "Migrating from dockershim"](/docs/tasks/administer-cluster/migrating-from-dockershim/)
|
||||
|
||||
* [Kubernetes Documentation: "Container runtimes"](/docs/setup/production-environment/container-runtimes/)
|
||||
|
||||
* [Kubernetes enhancement issue: "Removing dockershim from kubelet" (`kubernetes/enhancements#2221`)](https://github.com/kubernetes/enhancements/issues/2221)
|
||||
|
||||
* [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 Blog: "Dockershim removal is coming. Are you ready?", 2021/11/12](/blog/2021/11/12/are-you-ready-for-dockershim-removal/)
|
||||
-->
|
||||
|
||||
## 首要来源
|
||||
|
||||
* [Kubernetes 博客: “Dockershim 弃用常见问题解答”, 2020/12/02](/blog/2020/12/02/dockershim-faq/)
|
||||
|
||||
* [Kubernetes 文档：“从 dockershim 迁移”](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)
|
||||
|
||||
* [Kubernetes 文档：“容器运行时”](/zh/docs/setup/production-environment/container-runtimes/)
|
||||
|
||||
* [Kubernetes 增强提问: “从 kubelet 中删除 dockershim” (`kubernetes/enhancements#2221`)](https://github.com/kubernetes/enhancements/issues/2221)
|
||||
|
||||
* [Kubernetes 增强建议：“KEP-2221: 从 kubelet 中删除 dockershim”](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2221-remove-dockershim/README.md)
|
||||
|
||||
* [Kubernetes 博客: “移除 Dockershim 即将到来。你准备好了吗？”, 2021/11/12](/blog/2021/11/12/are-you-ready-for-dockershim-removal/)
|
||||
|
||||
<!--
|
||||
## Secondary sources
|
||||
|
||||
* [Docker.com blog: "What developers need to know about Docker, Docker Engine, and Kubernetes v1.20", 2020/12/04](https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/)
|
||||
|
||||
* [Tripwire.com: "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/)
|
||||
|
||||
* [Amazon EKS documentation: "Dockershim deprecation"](https://docs.aws.amazon.com/eks/latest/userguide/dockershim-deprecation.html)
|
||||
|
||||
* ["Google Open Source" channel on YouTube: "Learn Kubernetes with Google - Migrating from Dockershim to Containerd"](https://youtu.be/fl7_4hjT52g)
|
||||
|
||||
* [Mirantis Blog: "The Future of Dockershim is cri-dockerd", 2021/04/21](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/)
|
||||
|
||||
* [Github.com: "Mirantis/cri-dockerd" repo](https://github.com/Mirantis/cri-dockerd)
|
||||
-->
|
||||
## 次要来源
|
||||
|
||||
* [Docker.com 博客：“开发人员需要了解的关于 Docker、Docker Engine 和 Kubernetes v1.20 的哪些知识”，2020/12/04](https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/)
|
||||
|
||||
* [Tripwire.com：“Dockershim 即将弃用如何影响你的 Kubernetes”](https://www.tripwire.com/state-of-security/security-data-protection/cloud/how-dockershim-forthcoming-deprecation-affects-your-kubernetes/)
|
||||
|
||||
* [Amazon EKS 文档：“Dockershim 弃用”](https://docs.aws.amazon.com/eks/latest/userguide/dockershim-deprecation.html)
|
||||
|
||||
* [YouTube 上的 “Google 开源”频道：“与 Google 一起学习 Kubernetes - 从 Dockershim 迁移到 Containerd”](https://youtu.be/fl7_4hjT52g)
|
||||
|
||||
* [Mirantis 博客：“Dockershim 的未来是 cri-dockerd”，2021/04/21](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/)
|
||||
|
||||
* [Github.com：“Mirantis/cri-dockerd” 仓库](https://github.com/Mirantis/cri-dockerd)
|
||||
@@ -0,0 +1,799 @@
|
||||
---
|
||||
title: 使用 NUMA 感知的内存管理器
|
||||
content_type: task
|
||||
min-kubernetes-server-version: v1.21
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Utilizing the NUMA-aware Memory Manager
|
||||
|
||||
reviewers:
|
||||
- klueska
|
||||
- derekwaynecarr
|
||||
|
||||
content_type: task
|
||||
min-kubernetes-server-version: v1.21
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="v1.22" >}}
|
||||
|
||||
<!--
|
||||
The Kubernetes *Memory Manager* enables the feature of guaranteed memory (and hugepages)
|
||||
allocation for pods in the `Guaranteed` {{< glossary_tooltip text="QoS class" term_id="qos-class" >}}.
|
||||
|
||||
The Memory Manager employs hint generation protocol to yield the most suitable NUMA affinity for a pod.
|
||||
The Memory Manager feeds the central manager (*Topology Manager*) with these affinity hints.
|
||||
Based on both the hints and Topology Manager policy, the pod is rejected or admitted to the node.
|
||||
-->
|
||||
Kubernetes 内存管理器（Memory Manager）为 `Guaranteed`
|
||||
{{< glossary_tooltip text="QoS 类" term_id="qos-class" >}}
|
||||
的 Pods 提供可保证的内存（及大页面）分配能力。
|
||||
|
||||
内存管理器使用提示生成协议来为 Pod 生成最合适的 NUMA 亲和性配置。
|
||||
内存管理器将这类亲和性提示输入给中央管理器（即 Topology Manager）。
|
||||
基于所给的提示和 Topology Manager（拓扑管理器）的策略设置，Pod
|
||||
或者会被某节点接受，或者被该节点拒绝。
|
||||
|
||||
<!--
|
||||
Moreover, the Memory Manager ensures that the memory which a pod
|
||||
requests is allocated from
|
||||
a minimum number of NUMA nodes.
|
||||
|
||||
The Memory Manager is only pertinent to Linux based hosts.
|
||||
-->
|
||||
此外，内存管理器还确保 Pod 所请求的内存是从尽量少的 NUMA 节点分配而来。
|
||||
|
||||
内存管理器仅能用于 Linux 主机。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!--
|
||||
To align memory resources with other requested resources in a Pod Spec:
|
||||
|
||||
- the CPU Manager should be enabled and proper CPU Manager policy should be configured on a Node.
|
||||
See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/);
|
||||
- the Topology Manager should be enabled and proper Topology Manager policy should be configured on a Node.
|
||||
See [control Topology Management Policies](/docs/tasks/administer-cluster/topology-manager/).
|
||||
-->
|
||||
为了使得内存资源与 Pod 规约中所请求的其他资源对齐：
|
||||
|
||||
- CPU 管理器应该被启用，并且在节点（Node）上要配置合适的 CPU 管理器策略，
|
||||
参见[控制 CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/)；
|
||||
- 拓扑管理器要被启用，并且要在节点上配置合适的拓扑管理器策略，参见
|
||||
[控制拓扑管理器策略](/zh/docs/tasks/administer-cluster/topology-manager/)。
|
||||
|
||||
<!--
|
||||
Starting from v1.22, the Memory Manager is enabled by default through `MemoryManager`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
|
||||
|
||||
Preceding v1.22, the `kubelet` must be started with the following flag:
|
||||
|
||||
`--feature-gates=MemoryManager=true`
|
||||
|
||||
in order to enable the Memory Manager feature.
|
||||
-->
|
||||
从 v1.22 开始，内存管理器通过
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
`MemoryManager` 默认启用。
|
||||
|
||||
在 v1.22 之前，`kubelet` 必须在启动时设置如下标志：
|
||||
|
||||
`--feature-gates=MemoryManager=true`
|
||||
|
||||
这样内存管理器特性才会被启用。
|
||||
|
||||
<!--
|
||||
## How Memory Manager Operates?
|
||||
-->
|
||||
## 内存管理器如何运作？
|
||||
|
||||
<!--
|
||||
The Memory Manager currently offers the guaranteed memory (and hugepages) allocation
|
||||
for Pods in Guaranteed QoS class.
|
||||
To immediately put the Memory Manager into operation follow the guidelines in the section
|
||||
[Memory Manager configuration](#memory-manager-configuration), and subsequently,
|
||||
prepare and deploy a `Guaranteed` pod as illustrated in the section
|
||||
[Placing a Pod in the Guaranteed QoS class](#placing-a-pod-in-the-guaranteed-qos-class).
|
||||
-->
|
||||
内存管理器目前为 Guaranteed QoS 类中的 Pod 提供可保证的内存（和大页面）分配能力。
|
||||
若要立即将内存管理器启用，可参照[内存管理器配置](#memory-manager-configuration)节中的指南，
|
||||
之后按[将 Pod 放入 Guaranteed QoS 类](#placing-a-pod-in-the-guaranteed-qos-class)
|
||||
节中所展示的，准备并部署一个 `Guaranteed` Pod。
|
||||
|
||||
<!--
|
||||
The Memory Manager is a Hint Provider, and it provides topology hints for
|
||||
the Topology Manager which then aligns the requested resources according to these topology hints.
|
||||
It also enforces `cgroups` (i.e. `cpuset.mems`) for pods.
|
||||
The complete flow diagram concerning pod admission and deployment process is illustrated in
|
||||
[Memory Manager KEP: Design Overview][4] and below:
|
||||
-->
|
||||
内存管理器是一个提示驱动组件（Hint Provider），负责为拓扑管理器提供拓扑提示，
|
||||
后者根据这些拓扑提示对所请求的资源执行对齐操作。
|
||||
内存管理器也会为 Pods 应用 `cgroups` 设置（即 `cpuset.mems`）。
|
||||
与 Pod 准入和部署流程相关的完整流程图在[Memory Manager KEP: Design Overview][4]
|
||||
和下面。
|
||||
|
||||
<!--
|
||||
|
||||
-->
|
||||
|
||||
|
||||
<!--
|
||||
During this process, the Memory Manager updates its internal counters stored in
|
||||
[Node Map and Memory Maps][2] to manage guaranteed memory allocation.
|
||||
|
||||
The Memory Manager updates the Node Map during the startup and runtime as follows.
|
||||
-->
|
||||
在这个过程中，内存管理器会更新其内部存储于[节点映射和内存映射][2]中的计数器，
|
||||
从而管理有保障的内存分配。
|
||||
|
||||
内存管理器在启动和运行期间按下述逻辑更新节点映射（Node Map）。
|
||||
|
||||
<!--
|
||||
### Startup
|
||||
-->
|
||||
### 启动 {#startup}
|
||||
|
||||
<!--
|
||||
This occurs once a node administrator employs `--reserved-memory` (section
|
||||
[Reserved memory flag](#reserved-memory-flag)).
|
||||
In this case, the Node Map becomes updated to reflect this reservation as illustrated in
|
||||
[Memory Manager KEP: Memory Maps at start-up (with examples)][5].
|
||||
|
||||
The administrator must provide `--reserved-memory` flag when `Static` policy is configured.
|
||||
-->
|
||||
当节点管理员应用 `--reserved-memory` [预留内存标志](#reserved-memory-flag)时执行此逻辑。
|
||||
这时，节点映射会被更新以反映内存的预留，如
|
||||
[Memory Manager KEP: Memory Maps at start-up (with examples)][5]
|
||||
所说明。
|
||||
|
||||
当配置了 `Static` 策略时，管理员必须提供 `--reserved-memory` 标志设置。
|
||||
|
||||
<!--
|
||||
### Runtime
|
||||
-->
|
||||
### 运行时 {#runtime}
|
||||
|
||||
<!--
|
||||
Reference [Memory Manager KEP: Memory Maps at runtime (with examples)][6]
|
||||
illustrates how a successful pod deployment affects the Node Map, and it also relates to
|
||||
how potential Out-of-Memory (OOM) situations are handled further by Kubernetes or operating system.
|
||||
-->
|
||||
参考文献 [Memory Manager KEP: Memory Maps at runtime (with examples)][6]
|
||||
中说明了成功的 Pod 部署是如何影响节点映射的，该文档也解释了可能发生的内存不足
|
||||
（Out-of-memory，OOM）情况是如何进一步被 Kubernetes 或操作系统处理的。
|
||||
|
||||
<!--
|
||||
Important topic in the context of Memory Manager operation is the management of NUMA groups.
|
||||
Each time pod's memory request is in excess of single NUMA node capacity, the Memory Manager
|
||||
attempts to create a group that comprises several NUMA nodes and features extend memory capacity.
|
||||
The problem has been solved as elaborated in
|
||||
[Memory Manager KEP: How to enable the guaranteed memory allocation over many NUMA nodes?][3].
|
||||
Also, reference [Memory Manager KEP: Simulation - how the Memory Manager works? (by examples)][1]
|
||||
illustrates how the management of groups occurs.
|
||||
-->
|
||||
在内存管理器运作的语境中，一个重要的话题是对 NUMA 分组的管理。
|
||||
每当 Pod 的内存请求超出单个 NUMA 节点容量时，内存管理器会尝试创建一个包含多个
|
||||
NUMA 节点的分组，从而扩展内存容量。解决这个问题的详细描述在文档
|
||||
[Memory Manager KEP: How to enable the guaranteed memory allocation over many NUMA nodes?][3]
|
||||
中。同时，关于 NUMA 分组是如何管理的，你还可以参考文档
|
||||
[Memory Manager KEP: Simulation - how the Memory Manager works? (by examples)][1]。
|
||||
|
||||
<!--
|
||||
## Memory Manager configuration
|
||||
-->
|
||||
## 内存管理器配置 {#memory-manager-configuration}
|
||||
|
||||
<!--
|
||||
Other Managers should be first pre-configured. Next, the Memory Manger feature should be enabled
|
||||
and be run with `Static` policy (section [Static policy](#static-policy)).
|
||||
Optionally, some amount of memory can be reserved for system or kubelet processes to increase
|
||||
node stability (section [Reserved memory flag](#reserved-memory-flag)).
|
||||
-->
|
||||
其他管理器也要预先配置。接下来，内存管理器特性需要被启用，
|
||||
并且采用 `Static` 策略（[静态策略](#policy-static)）运行。
|
||||
作为可选操作，可以预留一定数量的内存给系统或者 kubelet 进程以增强节点的
|
||||
稳定性（[预留内存标志](#reserved-memory-flag)）。
|
||||
|
||||
<!--
|
||||
### Policies
|
||||
-->
|
||||
### 策略 {#policies}
|
||||
|
||||
<!--
|
||||
Memory Manager supports two policies. You can select a policy via a `kubelet` flag `--memory-manager-policy`:
|
||||
|
||||
* `None` (default)
|
||||
* `Static`
|
||||
-->
|
||||
内存管理器支持两种策略。你可以通过 `kubelet` 标志 `--memory-manager-policy` 来
|
||||
选择一种策略：
|
||||
|
||||
* `None` （默认）
|
||||
* `Static`
|
||||
|
||||
<!--
|
||||
#### None policy {#policy-none}
|
||||
|
||||
This is the default policy and does not affect the memory allocation in any way.
|
||||
It acts the same as if the Memory Manager is not present at all.
|
||||
|
||||
The `None` policy returns default topology hint. This special hint denotes that Hint Provider
|
||||
(Memory Manger in this case) has no preference for NUMA affinity with any resource.
|
||||
-->
|
||||
#### None 策略 {#policy-none}
|
||||
|
||||
这是默认的策略，并且不会以任何方式影响内存分配。该策略的行为好像内存管理器不存在一样。
|
||||
|
||||
`None` 策略返回默认的拓扑提示信息。这种特殊的提示会表明拓扑驱动组件（Hint Provider）
|
||||
（在这里是内存管理器）对任何资源都没有与 NUMA 亲和性关联的偏好。
|
||||
|
||||
<!--
|
||||
#### Static policy {#policy-static}
|
||||
|
||||
In the case of the `Guaranteed` pod, the `Static` Memory Manger policy returns topology hints
|
||||
relating to the set of NUMA nodes where the memory can be guaranteed,
|
||||
and reserves the memory through updating the internal [NodeMap][2] object.
|
||||
|
||||
In the case of the `BestEffort` or `Burstable` pod, the `Static` Memory Manager policy sends back
|
||||
the default topology hint as there is no request for the guaranteed memory,
|
||||
and does not reserve the memory in the internal [NodeMap][2] object.
|
||||
-->
|
||||
#### Static 策略 {#policy-static}
|
||||
|
||||
对 `Guaranteed` Pod 而言，`Static` 内存管理器策略会返回拓扑提示信息，该信息
|
||||
与内存分配有保障的 NUMA 节点集合有关，并且内存管理器还通过更新内部的
|
||||
[节点映射][2] 对象来完成内存预留。
|
||||
|
||||
对 `BestEffort` 或 `Burstable` Pod 而言，因为不存在对有保障的内存资源的请求，
|
||||
`Static` 内存管理器策略会返回默认的拓扑提示，并且不会通过内部的[节点映射][2]对象
|
||||
来预留内存。
|
||||
|
||||
<!--
|
||||
### Reserved memory flag
|
||||
-->
|
||||
### 预留内存标志 {#reserved-memory-flag}
|
||||
|
||||
<!--
|
||||
The [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/) mechanism
|
||||
is commonly used by node administrators to reserve K8S node system resources for the kubelet
|
||||
or operating system processes in order to enhance the node stability.
|
||||
A dedicated set of flags can be used for this purpose to set the total amount of reserved memory
|
||||
for a node. This pre-configured value is subsequently utilized to calculate
|
||||
the real amount of node's "allocatable" memory available to pods.
|
||||
-->
|
||||
[节点可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/)机制通常
|
||||
被节点管理员用来为 kubelet 或操作系统进程预留 K8S 节点上的系统资源，目的是提高节点稳定性。
|
||||
有一组专用的标志可用于这个目的，为节点设置总的预留内存量。
|
||||
此预配置的值接下来会被用来计算节点上对 Pods “可分配的”内存。
|
||||
|
||||
<!--
|
||||
The Kubernetes scheduler incorporates "allocatable" to optimise pod scheduling process.
|
||||
The foregoing flags include `--kube-reserved`, `--system-reserved` and `--eviction-threshold`.
|
||||
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.
|
||||
-->
|
||||
Kubernetes 调度器在优化 Pod 调度过程时，会考虑“可分配的”内存。
|
||||
前面提到的标志包括 `--kube-reserved`、`--system-reserved` 和 `--eviction-threshold`。
|
||||
这些标志值的综合计作预留内存的总量。
|
||||
|
||||
为内存管理器而新增加的 `--reserved-memory` 标志可以（让节点管理员）将总的预留内存进行划分，
|
||||
并完成跨 NUMA 节点的预留操作。
|
||||
|
||||
<!--
|
||||
The flag specifies a comma-separated list of memory reservations per NUMA node.
|
||||
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.
|
||||
|
||||
For example, if you have a NUMA node "NUMA0" with `10Gi` of memory available, and
|
||||
the `--reserved-memory` was specified to reserve `1Gi` of memory at "NUMA0",
|
||||
the Memory Manager assumes that only `9Gi` is available for containers.
|
||||
-->
|
||||
标志设置的值是一个按 NUMA 节点所给的内存预留的值的列表，用逗号分开。
|
||||
只有在内存管理器特性被启用的语境下，这个参数才有意义。
|
||||
内存管理器不会使用这些预留的内存来为容器负载分配内存。
|
||||
|
||||
例如，如果你有一个可用内存为 `10Gi` 的 NUMA 节点 "NUMA0"，而参数 `--reserved-memory`
|
||||
被设置成要在 "NUMA0" 上预留 `1Gi` 的内存，那么内存管理器会假定节点上只有 `9Gi`
|
||||
内存可用于容器负载。
|
||||
|
||||
<!--
|
||||
You can omit this parameter, however, you should be aware that the quantity of reserved memory
|
||||
from all NUMA nodes should be equal to the quantity of memory specified by the
|
||||
[Node Allocatable feature](/docs/tasks/administer-cluster/reserve-compute-resources/).
|
||||
If at least one node allocatable parameter is non-zero, you will need to specify
|
||||
`--reserved-memory` for at least one NUMA node.
|
||||
In fact, `eviction-hard` threshold value is equal to `100Mi` by default, so
|
||||
if `Static` policy is used, `--reserved-memory` is obligatory.
|
||||
-->
|
||||
你也可以忽略此参数，不过这样做时，你要清楚，所有 NUMA 节点上预留内存的数量要等于
|
||||
[节点可分配特性](/zh/docs/tasks/administer-cluster/reserve-compute-resources/)
|
||||
所设定的内存量。如果至少有一个节点可分配参数值为非零，你就需要至少为一个 NUMA
|
||||
节点设置 `--reserved-memory`。实际上，`eviction-hard` 阈值默认为 `100Mi`，
|
||||
所以当使用 `Static` 策略时，`--reserved-memory` 是必须设置的。
|
||||
|
||||
<!--
|
||||
Also, avoid the following configurations:
|
||||
|
||||
1. duplicates, i.e. the same NUMA node or memory type, but with a different value;
|
||||
1. setting zero limit for any of memory types;
|
||||
1. NUMA node IDs that do not exist in the machine hardware;
|
||||
1. memory type names different than `memory` or `hugepages-<size>`
|
||||
(hugepages of particular `<size>` should also exist).
|
||||
-->
|
||||
此外，应尽量避免如下配置：
|
||||
|
||||
1. 重复的配置，即同一 NUMA 节点或内存类型被设置不同的取值；
|
||||
1. 为某种内存类型设置约束值为零；
|
||||
1. 使用物理硬件上不存在的 NUMA 节点 ID；
|
||||
1. 使用名字不是 `memory` 或 `hugepages-<size>` 的内存类型名称
|
||||
（特定的 `<size>` 的大页面也必须存在）。
|
||||
|
||||
<!--
|
||||
Syntax:
|
||||
-->
|
||||
语法：
|
||||
|
||||
`--reserved-memory N:memory-type1=value1,memory-type2=value2,...`
|
||||
|
||||
<!--
|
||||
* `N` (integer) - NUMA node index, e.g. `0`
|
||||
* `memory-type` (string) - represents memory type:
|
||||
* `memory` - conventional memory
|
||||
* `hugepages-2Mi` or `hugepages-1Gi` - hugepages
|
||||
* `value` (string) - the quantity of reserved memory, e.g. `1Gi`
|
||||
-->
|
||||
* `N`（整数）- NUMA 节点索引，例如，`0`
|
||||
* `memory-type`（字符串）- 代表内存类型：
|
||||
* `memory` - 常规内存；
|
||||
* `hugepages-2Mi` 或 `hugepages-1Gi` - 大页面
|
||||
* `value`（字符串） - 预留内存的量，例如 `1Gi`
|
||||
|
||||
<!--
|
||||
Example usage:
|
||||
-->
|
||||
用法示例：
|
||||
|
||||
`--reserved-memory 0:memory=1Gi,hugepages-1Gi=2Gi`
|
||||
|
||||
<!-- or -->
|
||||
或者
|
||||
|
||||
`--reserved-memory 0:memory=1Gi --reserved-memory 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:
|
||||
|
||||
`sum(reserved-memory(i)) = kube-reserved + system-reserved + eviction-threshold`,
|
||||
|
||||
where `i` is an index of a NUMA node.
|
||||
-->
|
||||
当你为 `--reserved-memory` 标志指定取值时，必须要遵从之前通过节点可分配特性标志所设置的值。
|
||||
换言之，对每种内存类型而言都要遵从下面的规则：
|
||||
|
||||
`sum(reserved-memory(i)) = kube-reserved + system-reserved + eviction-threshold`
|
||||
|
||||
其中，`i` 是 NUMA 节点的索引。
|
||||
|
||||
<!--
|
||||
If you do not follow the formula above, the Memory Manager will show an error on startup.
|
||||
|
||||
In other words, the example above illustrates that for the conventional memory (`type=memory`),
|
||||
we reserve `3Gi` in total, i.e.:
|
||||
-->
|
||||
如果你不遵守上面的公示，内存管理器会在启动时输出错误信息。
|
||||
|
||||
换言之，上面的例子我们一共要预留 `3Gi` 的常规内存（`type=memory`），即：
|
||||
|
||||
`sum(reserved-memory(i)) = reserved-memory(0) + reserved-memory(1) = 1Gi + 2Gi = 3Gi`
|
||||
|
||||
<!--
|
||||
An example of kubelet command-line arguments relevant to the node Allocatable configuration:
|
||||
-->
|
||||
下面的例子中给出与节点可分配配置相关的 kubelet 命令行参数：
|
||||
|
||||
* `--kube-reserved=cpu=500m,memory=50Mi`
|
||||
* `--system-reserved=cpu=123m,memory=333Mi`
|
||||
* `--eviction-hard=memory.available<500Mi`
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The default hard eviction threshold is 100MiB, and **not** zero.
|
||||
Remember to increase the quantity of memory that you reserve by setting `--reserved-memory`
|
||||
by that hard eviction threshold. Otherwise, the kubelet will not start Memory Manager and
|
||||
display an error.
|
||||
-->
|
||||
默认的硬性驱逐阈值是 100MiB，**不是**零。
|
||||
请记得在使用 `--reserved-memory` 设置要预留的内存量时，加上这个硬性驱逐阈值。
|
||||
否则 kubelet 不会启动内存管理器，而会输出一个错误信息。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Here is an example of a correct configuration:
|
||||
-->
|
||||
下面是一个正确配置的示例：
|
||||
|
||||
```shell
|
||||
--feature-gates=MemoryManager=true
|
||||
--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
|
||||
```
|
||||
|
||||
<!--
|
||||
Let us validate the configuration above:
|
||||
-->
|
||||
我们对上面的配置做一个检查：
|
||||
|
||||
1. `kube-reserved + system-reserved + eviction-hard(default) = reserved-memory(0) + reserved-memory(1)`
|
||||
1. `4GiB + 1GiB + 100MiB = 3GiB + 2148MiB`
|
||||
1. `5120MiB + 100MiB = 3072MiB + 2148MiB`
|
||||
1. `5220MiB = 5220MiB` （这是对的）
|
||||
|
||||
<!--
|
||||
## Placing a Pod in the Guaranteed QoS class
|
||||
|
||||
If the selected policy is anything other than `None`, the Memory Manager identifies pods
|
||||
that are in the `Guaranteed` QoS class.
|
||||
The Memory Manager provides specific topology hints to the Topology Manager for each `Guaranteed` pod.
|
||||
For pods in a QoS class other than `Guaranteed`, the Memory Manager provides default topology hints
|
||||
to the Topology Manager.
|
||||
-->
|
||||
## 将 Pod 放入 Guaranteed QoS 类 {#placing-a-pod-in-the-guaranteed-qos-class}
|
||||
|
||||
若所选择的策略不是 `None`，则内存管理器会辨识处于 `Guaranteed` QoS 类中的 Pod。
|
||||
内存管理器为每个 `Guaranteed` Pod 向拓扑管理器提供拓扑提示信息。
|
||||
对于不在 `Guaranteed` QoS 类中的其他 Pod，内存管理器向拓扑管理器提供默认的
|
||||
拓扑提示信息。
|
||||
|
||||
<!--
|
||||
The following excerpts from pod manifests assign a pod to the `Guaranteed` QoS class.
|
||||
|
||||
Pod with integer CPU(s) runs in the `Guaranteed` QoS class, when `requests` are equal to `limits`:
|
||||
-->
|
||||
下面的来自 Pod 清单的片段将 Pod 加入到 `Guaranteed` QoS 类中。
|
||||
|
||||
当 Pod 的 CPU `requests` 等于 `limits` 且为整数值时，Pod 将运行在 `Guaranteed`
|
||||
QoS 类中。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
cpu: "2"
|
||||
example.com/device: "1"
|
||||
requests:
|
||||
memory: "200Mi"
|
||||
cpu: "2"
|
||||
example.com/device: "1"
|
||||
```
|
||||
|
||||
<!--
|
||||
Also, a pod sharing CPU(s) runs in the `Guaranteed` QoS class, when `requests` are equal to `limits`.
|
||||
-->
|
||||
此外，共享 CPU 的 Pods 在 `requests` 等于 `limits` 值时也运行在 `Guaranteed`
|
||||
QoS 类中。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
cpu: "300m"
|
||||
example.com/device: "1"
|
||||
requests:
|
||||
memory: "200Mi"
|
||||
cpu: "300m"
|
||||
example.com/device: "1"
|
||||
```
|
||||
|
||||
<!--
|
||||
Notice that both CPU and memory requests must be specified for a Pod to lend it to Guaranteed QoS class.
|
||||
-->
|
||||
要注意的是，只有 CPU 和内存请求都被设置时，Pod 才会进入 Guaranteed QoS 类。
|
||||
|
||||
<!--
|
||||
## Troubleshooting
|
||||
|
||||
The following means can be used to troubleshoot the reason why a pod could not be deployed or
|
||||
became rejected at a node:
|
||||
-->
|
||||
## 故障排查 {#troubleshooting}
|
||||
|
||||
下面的方法可用来排查为什么 Pod 无法被调度或者被节点拒绝：
|
||||
|
||||
<!--
|
||||
- pod status - indicates topology affinity errors
|
||||
- system logs - include valuable information for debugging, e.g., about generated hints
|
||||
- state file - the dump of internal state of the Memory Manager
|
||||
(includes [Node Map and Memory Maps][2])
|
||||
- starting from v1.22, the [device plugin resource API](#device-plugin-resource-api) can be used
|
||||
to retrieve information about the memory reserved for containers
|
||||
-->
|
||||
- Pod 状态 - 可表明拓扑亲和性错误
|
||||
- 系统日志 - 包含用来调试的有价值的信息，例如，关于所生成的提示信息
|
||||
- 状态文件 - 其中包含内存管理器内部状态的转储（包含[节点映射和内存映射][2]）
|
||||
- 从 v1.22 开始，[设备插件资源 API](#device-plugin-resource-api) 可以用来
|
||||
检索关于为容器预留的内存的信息
|
||||
|
||||
<!--
|
||||
### Pod status (TopologyAffinityError) {#TopologyAffinityError}
|
||||
|
||||
This error typically occurs in the following situations:
|
||||
|
||||
* a node has not enough resources available to satisfy the pod's request
|
||||
* the pod's request is rejected due to particular Topology Manager policy constraints
|
||||
|
||||
The error appears in the status of a pod:
|
||||
-->
|
||||
### Pod 状态 （TopologyAffinityError） {#TopologyAffinityError}
|
||||
|
||||
这类错误通常在以下情形出现：
|
||||
|
||||
* 节点缺少足够的资源来满足 Pod 请求
|
||||
* Pod 的请求因为特定的拓扑管理器策略限制而被拒绝
|
||||
|
||||
错误信息会出现在 Pod 的状态中：
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
```none
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
guaranteed 0/1 TopologyAffinityError 0 113s
|
||||
```
|
||||
|
||||
<!--
|
||||
Use `kubectl describe pod <id>` or `kubectl get events` to obtain detailed error message:
|
||||
-->
|
||||
使用 `kubectl describe pod <id>` 或 `kubectl get events` 可以获得详细的错误信息。
|
||||
|
||||
```none
|
||||
Warning TopologyAffinityError 10m kubelet, dell8 Resources cannot be allocated with Topology locality
|
||||
```
|
||||
|
||||
<!--
|
||||
### System logs
|
||||
|
||||
Search system logs with respect to a particular pod.
|
||||
|
||||
The set of hints that Memory Manager generated for the pod can be found in the logs.
|
||||
Also, the set of hints generated by CPU Manager should be present in the logs.
|
||||
-->
|
||||
### 系统日志 {#system-logs}
|
||||
|
||||
针对特定的 Pod 搜索系统日志。
|
||||
|
||||
内存管理器为 Pod 所生成的提示信息可以在日志中找到。
|
||||
此外，日志中应该也存在 CPU 管理器所生成的提示信息。
|
||||
|
||||
<!--
|
||||
Topology Manager merges these hints to calculate a single best hint.
|
||||
The best hint should be also present in the logs.
|
||||
|
||||
The best hint indicates where to allocate all the resources.
|
||||
Topology Manager tests this hint against its current policy, and based on the verdict,
|
||||
it either admits the pod to the node or rejects it.
|
||||
|
||||
Also, search the logs for occurrences associated with the Memory Manager,
|
||||
e.g. to find out information about `cgroups` and `cpuset.mems` updates.
|
||||
-->
|
||||
拓扑管理器将这些提示信息进行合并，计算得到唯一的最合适的提示数据。
|
||||
此最佳提示数据也应该出现在日志中。
|
||||
|
||||
最佳提示表明要在哪里分配所有的资源。拓扑管理器会用当前的策略来测试此数据，
|
||||
并基于得出的结论或者接纳 Pod 到节点，或者将其拒绝。
|
||||
|
||||
此外，你可以搜索日志查找与内存管理器相关的其他条目，例如 `cgroups` 和
|
||||
`cpuset.mems` 的更新信息等。
|
||||
|
||||
<!--
|
||||
### Examine the memory manager state on a node
|
||||
|
||||
Let us first deploy a sample `Guaranteed` pod whose specification is as follows:
|
||||
-->
|
||||
### 检查节点上内存管理器状态
|
||||
|
||||
我们首先部署一个 `Guaranteed` Pod 示例，其规约如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: guaranteed
|
||||
spec:
|
||||
containers:
|
||||
- name: guaranteed
|
||||
image: consumer
|
||||
imagePullPolicy: Never
|
||||
resources:
|
||||
limits:
|
||||
cpu: "2"
|
||||
memory: 150Gi
|
||||
requests:
|
||||
cpu: "2"
|
||||
memory: 150Gi
|
||||
command: ["sleep","infinity"]
|
||||
```
|
||||
|
||||
<!--
|
||||
Next, let us log into the node where it was deployed and examine the state file in
|
||||
`/var/lib/kubelet/memory_manager_state`:
|
||||
-->
|
||||
接下来，我们登录到 Pod 运行所在的节点，检查位于
|
||||
`/var/lib/kubelet/memory_manager_state` 的状态文件：
|
||||
|
||||
```json
|
||||
{
|
||||
"policyName":"Static",
|
||||
"machineState":{
|
||||
"0":{
|
||||
"numberOfAssignments":1,
|
||||
"memoryMap":{
|
||||
"hugepages-1Gi":{
|
||||
"total":0,
|
||||
"systemReserved":0,
|
||||
"allocatable":0,
|
||||
"reserved":0,
|
||||
"free":0
|
||||
},
|
||||
"memory":{
|
||||
"total":134987354112,
|
||||
"systemReserved":3221225472,
|
||||
"allocatable":131766128640,
|
||||
"reserved":131766128640,
|
||||
"free":0
|
||||
}
|
||||
},
|
||||
"nodes":[
|
||||
0,
|
||||
1
|
||||
]
|
||||
},
|
||||
"1":{
|
||||
"numberOfAssignments":1,
|
||||
"memoryMap":{
|
||||
"hugepages-1Gi":{
|
||||
"total":0,
|
||||
"systemReserved":0,
|
||||
"allocatable":0,
|
||||
"reserved":0,
|
||||
"free":0
|
||||
},
|
||||
"memory":{
|
||||
"total":135286722560,
|
||||
"systemReserved":2252341248,
|
||||
"allocatable":133034381312,
|
||||
"reserved":29295144960,
|
||||
"free":103739236352
|
||||
}
|
||||
},
|
||||
"nodes":[
|
||||
0,
|
||||
1
|
||||
]
|
||||
}
|
||||
},
|
||||
"entries":{
|
||||
"fa9bdd38-6df9-4cf9-aa67-8c4814da37a8":{
|
||||
"guaranteed":[
|
||||
{
|
||||
"numaAffinity":[
|
||||
0,
|
||||
1
|
||||
],
|
||||
"type":"memory",
|
||||
"size":161061273600
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
"checksum":4142013182
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
It can be deduced from the state file that the pod was pinned to both NUMA nodes, i.e.:
|
||||
-->
|
||||
从这个状态文件，可以推断 Pod 被同时绑定到两个 NUMA 节点，即：
|
||||
|
||||
```json
|
||||
"numaAffinity":[
|
||||
0,
|
||||
1
|
||||
],
|
||||
```
|
||||
|
||||
<!--
|
||||
Pinned term means that pod's memory consumption is constrained (through `cgroups` configuration)
|
||||
to these NUMA nodes.
|
||||
|
||||
This automatically implies that Memory Manager instantiated a new group that
|
||||
comprises these two NUMA nodes, i.e. `0` and `1` indexed NUMA nodes.
|
||||
-->
|
||||
术语绑定（pinned）意味着 Pod 的内存使用被（通过 `cgroups` 配置）限制到
|
||||
这些 NUMA 节点。
|
||||
|
||||
这也直接意味着内存管理器已经创建了一个 NUMA 分组，由这两个 NUMA 节点组成，
|
||||
即索引值分别为 `0` 和 `1` 的 NUMA 节点。
|
||||
|
||||
<!--
|
||||
Notice that the management of groups is handled in a relatively complex manner, and
|
||||
further elaboration is provided in Memory Manager KEP in [this][1] and [this][3] sections.
|
||||
|
||||
In order to analyse memory resources available in a group,the corresponding entries from
|
||||
NUMA nodes belonging to the group must be added up.
|
||||
-->
|
||||
注意 NUMA 分组的管理是有一个相对复杂的管理器处理的，相关逻辑的进一步细节可在内存管理器的
|
||||
KEP 中[示例1][1]和[跨 NUMA 节点][3]节找到。
|
||||
|
||||
为了分析 NUMA 组中可用的内存资源，必须对分组内 NUMA 节点对应的条目进行汇总。
|
||||
|
||||
<!--
|
||||
For example, the total amount of free "conventional" memory in the group can be computed
|
||||
by adding up the free memory available at every NUMA node in the group,
|
||||
i.e., in the `"memory"` section of NUMA node `0` (`"free":0`) and NUMA node `1` (`"free":103739236352`).
|
||||
So, the total amount of free "conventional" memory in this group is equal to `0 + 103739236352` bytes.
|
||||
-->
|
||||
例如，NUMA 分组中空闲的“常规”内存的总量可以通过将分组内所有 NUMA
|
||||
节点上空闲内存加和来计算，即将 NUMA 节点 `0` 和 NUMA 节点 `1` 的 `"memory"` 节
|
||||
（分别是 `"free":0` 和 `"free": 103739236352`）相加，得到此分组中空闲的“常规”
|
||||
内存总量为 `0 + 103739236352` 字节。
|
||||
|
||||
<!--
|
||||
The line `"systemReserved":3221225472` indicates that the administrator of this node reserved
|
||||
`3221225472` bytes (i.e. `3Gi`) to serve kubelet and system processes at NUMA node `0`,
|
||||
by using `--reserved-memory` flag.
|
||||
-->
|
||||
`"systemReserved": 3221225472` 这一行表明节点的管理员使用 `--reserved-memory` 为 NUMA
|
||||
节点 `0` 上运行的 kubelet 和系统进程预留了 `3221225472` 字节 （即 `3Gi`）。
|
||||
|
||||
<!--
|
||||
### Device plugin resource API
|
||||
|
||||
By employing the [API](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/),
|
||||
the information about reserved memory for each container can be retrieved, which is contained
|
||||
in protobuf `ContainerMemory` message.
|
||||
This information can be retrieved solely for pods in Guaranteed QoS class.
|
||||
-->
|
||||
### 设备插件资源 API {#device-plugin-resource-api}
|
||||
|
||||
通过使用此 [API](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)，
|
||||
可以获得每个容器的预留内存信息，该信息位于 protobuf 协议的 `ContainerMemory` 消息中。
|
||||
只能针对 Guaranteed QoS 类中的 Pod 来检索此信息。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
以下均为英文设计文档，因此其标题不翻译。
|
||||
-->
|
||||
- [Memory Manager KEP: Design Overview][4]
|
||||
- [Memory Manager KEP: Memory Maps at start-up (with examples)][5]
|
||||
- [Memory Manager KEP: Memory Maps at runtime (with examples)][6]
|
||||
- [Memory Manager KEP: Simulation - how the Memory Manager works? (by examples)][1]
|
||||
- [Memory Manager KEP: The Concept of Node Map and Memory Maps][2]
|
||||
- [Memory Manager KEP: How to enable the guaranteed memory allocation over many NUMA nodes?][3]
|
||||
|
||||
[1]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#simulation---how-the-memory-manager-works-by-examples
|
||||
[2]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#the-concept-of-node-map-and-memory-maps
|
||||
[3]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#how-to-enable-the-guaranteed-memory-allocation-over-many-numa-nodes
|
||||
[4]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#design-overview
|
||||
[5]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#memory-maps-at-start-up-with-examples
|
||||
[6]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#memory-maps-at-runtime-with-examples
|
||||
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: "集群"
|
||||
weight: 60
|
||||
---
|
||||
+290
-183
@@ -3,58 +3,69 @@ title: 使用 AppArmor 限制容器对资源的访问
|
||||
content_type: tutorial
|
||||
weight: 10
|
||||
---
|
||||
<!-- ---
|
||||
reviewers:
|
||||
- stclair
|
||||
<!--
|
||||
title: Restrict a Container's Access to Resources with AppArmor
|
||||
content_type: tutorial
|
||||
weight: 10
|
||||
--- -->
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.4" state="beta" >}}
|
||||
|
||||
|
||||
<!-- AppArmor is a Linux kernel security module that supplements the standard Linux user and group based
|
||||
<!--
|
||||
AppArmor is a Linux kernel security module that supplements the standard Linux user and group based
|
||||
permissions to confine programs to a limited set of resources. AppArmor can be configured for any
|
||||
application to reduce its potential attack surface and provide greater in-depth defense. It is
|
||||
configured through profiles tuned to allow the access needed by a specific program or container,
|
||||
such as Linux capabilities, network access, file permissions, etc. Each profile can be run in either
|
||||
*enforcing* mode, which blocks access to disallowed resources, or *complain* mode, which only reports
|
||||
violations. -->
|
||||
Apparmor 是一个 Linux 内核安全模块，它补充了标准的基于 Linux 用户和组的安全模块将程序限制为有限资源集的权限。
|
||||
violations.
|
||||
-->
|
||||
AppArmor 是一个 Linux 内核安全模块，
|
||||
它补充了基于标准 Linux 用户和组的权限，将程序限制在一组有限的资源中。
|
||||
AppArmor 可以配置为任何应用程序减少潜在的攻击面，并且提供更加深入的防御。
|
||||
AppArmor 是通过配置文件进行配置的，这些配置文件被调整为允许特定程序或者容器访问，如 Linux 功能、网络访问、文件权限等。
|
||||
每个配置文件都可以在*强制（enforcing）*模式（阻止访问不允许的资源）或*投诉（complain）*模式
|
||||
（仅报告冲突）下运行。
|
||||
|
||||
|
||||
它通过调整配置文件进行配置，以允许特定程序或容器所需的访问，
|
||||
如 Linux 权能字、网络访问、文件权限等。
|
||||
每个配置文件都可以在
|
||||
*强制（enforcing）* 模式（阻止访问不允许的资源）或
|
||||
*投诉（complain）* 模式（仅报告冲突）下运行。
|
||||
|
||||
<!--
|
||||
AppArmor can help you to run a more secure deployment by restricting what containers are allowed to
|
||||
do, and/or provide better auditing through system logs. However, it is important to keep in mind
|
||||
that AppArmor is not a silver bullet and can only do so much to protect against exploits in your
|
||||
application code. It is important to provide good, restrictive profiles, and harden your
|
||||
applications and cluster from other angles as well.
|
||||
-->
|
||||
AppArmor 可以通过限制允许容器执行的操作，
|
||||
和/或通过系统日志提供更好的审计来帮助你运行更安全的部署。
|
||||
但是，重要的是要记住 AppArmor 不是灵丹妙药，
|
||||
只能做部分事情来防止应用程序代码中的漏洞。
|
||||
提供良好的限制性配置文件，并从其他角度强化你的应用程序和集群非常重要。
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
|
||||
<!-- * See an example of how to load a profile on a node
|
||||
<!--
|
||||
* See an example of how to load a profile on a node
|
||||
* Learn how to enforce the profile on a Pod
|
||||
* Learn how to check that the profile is loaded
|
||||
* See what happens when a profile is violated
|
||||
* See what happens when a profile cannot be loaded -->
|
||||
* See what happens when a profile cannot be loaded
|
||||
-->
|
||||
* 查看如何在节点上加载配置文件示例
|
||||
* 了解如何在 Pod 上强制执行配置文件
|
||||
* 了解如何检查配置文件是否已加载
|
||||
* 查看违反配置文件时会发生什么情况
|
||||
* 查看无法加载配置文件时会发生什么情况
|
||||
|
||||
|
||||
* 查看违反配置文件时会发生什么
|
||||
* 查看无法加载配置文件时会发生什么
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
<!-- Make sure: -->
|
||||
务必：
|
||||
确保：
|
||||
|
||||
<!-- 1. Kubernetes version is at least v1.4 -- Kubernetes support for AppArmor was added in
|
||||
<!--
|
||||
1. Kubernetes version is at least v1.4 -- Kubernetes support for AppArmor was added in
|
||||
v1.4. Kubernetes components older than v1.4 are not aware of the new AppArmor annotations, and
|
||||
will **silently ignore** any AppArmor settings that are provided. To ensure that your Pods are
|
||||
receiving the expected protections, it is important to verify the Kubelet version of your nodes:
|
||||
@@ -66,10 +77,14 @@ AppArmor 是通过配置文件进行配置的，这些配置文件被调整为
|
||||
gke-test-default-pool-239f5d02-gyn2: v1.4.0
|
||||
gke-test-default-pool-239f5d02-x1kf: v1.4.0
|
||||
gke-test-default-pool-239f5d02-xwux: v1.4.0
|
||||
``` -->
|
||||
1. Kubernetes 版本至少是 v1.4 -- AppArmor 在 Kubernetes v1.4 版本中才添加了对 AppArmor 的支持。早于 v1.4 版本的 Kubernetes 组件不知道新的 AppArmor 注释，并且将会 **默认忽略** 提供的任何 AppArmor 设置。为了确保您的 Pods 能够得到预期的保护，必须验证节点的 Kubelet 版本：
|
||||
```
|
||||
-->
|
||||
1. Kubernetes 版本至少是 v1.4 —— AppArmor 在 Kubernetes v1.4 版本中才添加了对 AppArmor 的支持。
|
||||
早于 v1.4 版本的 Kubernetes 组件不知道新的 AppArmor 注解
|
||||
并且将会 **默认忽略** 提供的任何 AppArmor 设置。
|
||||
为了确保你的 Pod 能够得到预期的保护，必须验证节点的 Kubelet 版本：
|
||||
|
||||
```shell
|
||||
```shell
|
||||
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}\n{end}'
|
||||
```
|
||||
```
|
||||
@@ -78,7 +93,8 @@ AppArmor 是通过配置文件进行配置的，这些配置文件被调整为
|
||||
gke-test-default-pool-239f5d02-xwux: v1.4.0
|
||||
```
|
||||
|
||||
<!-- 2. AppArmor kernel module is enabled -- For the Linux kernel to enforce an AppArmor profile, the
|
||||
<!--
|
||||
2. AppArmor kernel module is enabled -- For the Linux kernel to enforce an AppArmor profile, the
|
||||
AppArmor kernel module must be installed and enabled. Several distributions enable the module by
|
||||
default, such as Ubuntu and SUSE, and many others provide optional support. To check whether the
|
||||
module is enabled, check the `/sys/module/apparmor/parameters/enabled` file:
|
||||
@@ -95,47 +111,40 @@ AppArmor 是通过配置文件进行配置的，这些配置文件被调整为
|
||||
Ubuntu carries many AppArmor patches that have not been merged into the upstream Linux
|
||||
kernel, including patches that add additional hooks and features. Kubernetes has only been
|
||||
tested with the upstream version, and does not promise support for other features.
|
||||
{{< /note >}} -->
|
||||
2. AppArmor 内核模块已启用 -- 要使 Linux 内核强制执行 AppArmor 配置文件，必须安装并且启动 AppArmor 内核模块。默认情况下，有几个发行版支持该模块，如 Ubuntu 和 SUSE，还有许多发行版提供可选支持。要检查模块是否已启用，请检查
|
||||
`/sys/module/apparmor/parameters/enabled` 文件：
|
||||
```shell
|
||||
{{< /note >}}
|
||||
-->
|
||||
2. AppArmor 内核模块已启用 —— 要使 Linux 内核强制执行 AppArmor 配置文件，
|
||||
必须安装并且启动 AppArmor 内核模块。默认情况下，有几个发行版支持该模块，
|
||||
如 Ubuntu 和 SUSE，还有许多发行版提供可选支持。要检查模块是否已启用，请检查
|
||||
`/sys/module/apparmor/parameters/enabled` 文件：
|
||||
|
||||
```shell
|
||||
cat /sys/module/apparmor/parameters/enabled
|
||||
Y
|
||||
```
|
||||
如果 Kubelet 包含 AppArmor 支持(>=v1.4)，如果内核模块未启用，它将拒绝运行带有 AppArmor 选项的 Pod。
|
||||
|
||||
如果 Kubelet 包含 AppArmor 支持（>= v1.4），
|
||||
但是内核模块未启用，它将拒绝运行带有 AppArmor 选项的 Pod。
|
||||
|
||||
{{< note >}}
|
||||
Ubuntu 携带了许多没有合并到上游 Linux 内核中的 AppArmor 补丁，包括添加附加钩子和特性的补丁。Kubernetes 只在上游版本中测试过，不承诺支持其他特性。
|
||||
Ubuntu 携带了许多没有合并到上游 Linux 内核中的 AppArmor 补丁，
|
||||
包括添加附加钩子和特性的补丁。Kubernetes 只在上游版本中测试过，不承诺支持其他特性。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- 3. Container runtime is Docker -- Currently the only Kubernetes-supported container runtime that
|
||||
also supports AppArmor is Docker. As more runtimes add AppArmor support, the options will be
|
||||
expanded. You can verify that your nodes are running docker with:
|
||||
<!--
|
||||
3. Container runtime supports AppArmor -- Currently all common Kubernetes-supported container
|
||||
runtimes should support AppArmor, like {{< glossary_tooltip term_id="docker">}},
|
||||
{{< glossary_tooltip term_id="cri-o" >}} or {{< glossary_tooltip term_id="containerd" >}}.
|
||||
Please refer to the corresponding runtime documentation and verify that the cluster fulfills
|
||||
the requirements to use AppArmor.
|
||||
-->
|
||||
3. 容器运行时支持 AppArmor —— 目前所有常见的 Kubernetes 支持的容器运行时都应该支持 AppArmor，
|
||||
像 {{< glossary_tooltip term_id="docker">}}，{{< glossary_tooltip term_id="cri-o" >}}
|
||||
或 {{< glossary_tooltip term_id="containerd" >}}。
|
||||
请参考相应的运行时文档并验证集群是否满足使用 AppArmor 的要求。
|
||||
|
||||
```shell
|
||||
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.containerRuntimeVersion}\n{end}'
|
||||
```
|
||||
```
|
||||
gke-test-default-pool-239f5d02-gyn2: docker://1.11.2
|
||||
gke-test-default-pool-239f5d02-x1kf: docker://1.11.2
|
||||
gke-test-default-pool-239f5d02-xwux: docker://1.11.2
|
||||
```
|
||||
|
||||
If the Kubelet contains AppArmor support (>= v1.4), it will refuse to run a Pod with AppArmor
|
||||
options if the runtime is not Docker. -->
|
||||
3. Docker 作为容器运行环境 -- 目前，支持 Kubernetes 运行的容器中只有 Docker 也支持 AppArmor。随着更多的运行时添加 AppArmor 的支持，可选项将会增多。您可以使用以下命令验证节点是否正在运行 Docker:
|
||||
```shell
|
||||
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.containerRuntimeVersion}\n{end}'
|
||||
```
|
||||
```
|
||||
gke-test-default-pool-239f5d02-gyn2: docker://1.11.2
|
||||
gke-test-default-pool-239f5d02-x1kf: docker://1.11.2
|
||||
gke-test-default-pool-239f5d02-xwux: docker://1.11.2
|
||||
```
|
||||
|
||||
如果 Kubelet 包含 AppArmor 支持(>=v1.4)，如果运行环境不是 Docker，它将拒绝运行带有 AppArmor 选项的 Pod。
|
||||
|
||||
<!-- 4. Profile is loaded -- AppArmor is applied to a Pod by specifying an AppArmor profile that each
|
||||
<!--
|
||||
4. Profile is loaded -- AppArmor is applied to a Pod by specifying an AppArmor profile that each
|
||||
container should be run with. If any of the specified profiles is not already loaded in the
|
||||
kernel, the Kubelet (>= v1.4) will reject the Pod. You can view which profiles are loaded on a
|
||||
node by checking the `/sys/kernel/security/apparmor/profiles` file. For example:
|
||||
@@ -151,8 +160,13 @@ AppArmor 是通过配置文件进行配置的，这些配置文件被调整为
|
||||
```
|
||||
|
||||
For more details on loading profiles on nodes, see
|
||||
[Setting up nodes with profiles](#setting-up-nodes-with-profiles). -->
|
||||
4. 配置文件已加载 -- 通过指定每个容器都应使用 AppArmor 配置文件，AppArmor 应用于 Pod。如果指定的任何配置文件尚未加载到内核， Kubelet (>=v1.4) 将拒绝 Pod。通过检查 `/sys/kernel/security/apparmor/profiles` 文件，可以查看节点加载了哪些配置文件。例如:
|
||||
[Setting up nodes with profiles](#setting-up-nodes-with-profiles).
|
||||
-->
|
||||
4. 配置文件已加载 —— 通过指定每个容器都应使用的 AppArmor 配置文件，
|
||||
AppArmor 会被应用到 Pod 上。如果指定的任何配置文件尚未加载到内核，
|
||||
Kubelet（>= v1.4） 将拒绝 Pod。
|
||||
通过检查 `/sys/kernel/security/apparmor/profiles` 文件，
|
||||
可以查看节点加载了哪些配置文件。例如:
|
||||
|
||||
```shell
|
||||
ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort"
|
||||
@@ -164,15 +178,17 @@ AppArmor 是通过配置文件进行配置的，这些配置文件被调整为
|
||||
k8s-nginx (enforce)
|
||||
```
|
||||
|
||||
<!-- For more details on loading profiles on nodes, see
|
||||
[Setting up nodes with profiles](#setting-up-nodes-with-profiles). -->
|
||||
有关在节点上加载配置文件的详细信息，请参见[使用配置文件设置节点](#setting-up-nodes-with-profiles)。
|
||||
|
||||
<!-- As long as the Kubelet version includes AppArmor support (>= v1.4), the Kubelet will reject a Pod
|
||||
<!--
|
||||
As long as the Kubelet version includes AppArmor support (>= v1.4), the Kubelet will reject a Pod
|
||||
with AppArmor options if any of the prerequisites are not met. You can also verify AppArmor support
|
||||
on nodes by checking the node ready condition message (though this is likely to be removed in a
|
||||
later release): -->
|
||||
只要 Kubelet 版本包含 AppArmor 支持(>=v1.4)，如果不满足任何先决条件，Kubelet 将拒绝带有 AppArmor 选项的 Pod。您还可以通过检查节点就绪状况消息来验证节点上的 AppArmor 支持(尽管这可能会在以后的版本中删除)：
|
||||
later release):
|
||||
-->
|
||||
只要 Kubelet 版本包含 AppArmor 支持(>=v1.4)，
|
||||
如果不满足这些先决条件，Kubelet 将拒绝带有 AppArmor 选项的 Pod。
|
||||
你还可以通过检查节点就绪状况消息来验证节点上的 AppArmor 支持（尽管这可能会在以后的版本中删除）：
|
||||
|
||||
```shell
|
||||
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}'
|
||||
@@ -183,49 +199,67 @@ gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor e
|
||||
gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled
|
||||
```
|
||||
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
<!-- ## Securing a Pod -->
|
||||
## 保护 Pod
|
||||
## 保护 Pod {#securing-a-pod}
|
||||
|
||||
{{< note >}}
|
||||
<!-- AppArmor is currently in beta, so options are specified as annotations. Once support graduates to
|
||||
<!--
|
||||
AppArmor is currently in beta, so options are specified as annotations. Once support graduates to
|
||||
general availability, the annotations will be replaced with first-class fields (more details in
|
||||
[Upgrade path to GA](#upgrade-path-to-general-availability)). -->
|
||||
AppArmor 目前处于测试阶段，因此选项被指定为注释。一旦 AppArmor 被授予支持通用，注释将替换为首要的字段(更多详情参见[升级到 GA 的途径](#upgrade-path-to-general-availability))。
|
||||
[Upgrade path to GA](#upgrade-path-to-general-availability)).
|
||||
-->
|
||||
AppArmor 目前处于 Beta 阶段，因此选项以注解形式设定。
|
||||
一旦 AppArmor 支持进入正式发布阶段，注解将被替换为一阶的资源字段
|
||||
（更多详情参见[升级到 GA 的途径](#upgrade-path-to-general-availability)）。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- AppArmor profiles are specified *per-container*. To specify the AppArmor profile to run a Pod
|
||||
container with, add an annotation to the Pod's metadata: -->
|
||||
AppArmor 配置文件被指定为 *per-container*。要指定要用其运行 Pod 容器的 AppArmor 配置文件，请向 Pod 的元数据添加注释：
|
||||
<!--
|
||||
AppArmor profiles are specified *per-container*. To specify the AppArmor profile to run a Pod
|
||||
container with, add an annotation to the Pod's metadata:
|
||||
-->
|
||||
AppArmor 配置文件是按 *逐个容器* 的形式来设置的。
|
||||
要指定用来运行 Pod 容器的 AppArmor 配置文件，请向 Pod 的 metadata 添加注解：
|
||||
|
||||
```yaml
|
||||
container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>
|
||||
```
|
||||
|
||||
<!-- Where `<container_name>` is the name of the container to apply the profile to, and `<profile_ref>`
|
||||
specifies the profile to apply. The `profile_ref` can be one of: -->
|
||||
`<container_name>` 的名称是容器的简称，用以描述简介，并且简称为 `<profile_ref>` 。`<profile_ref>` 可以作为其中之一：
|
||||
<!--
|
||||
Where `<container_name>` is the name of the container to apply the profile to, and `<profile_ref>`
|
||||
specifies the profile to apply. The `profile_ref` can be one of:
|
||||
-->
|
||||
`<container_name>` 的名称是配置文件所针对的容器的名称，`<profile_def>` 则设置要应用的配置文件。
|
||||
`<profile_ref>` 可以是以下取值之一：
|
||||
|
||||
<!-- * `runtime/default` to apply the runtime's default profile
|
||||
<!--
|
||||
* `runtime/default` to apply the runtime's default profile
|
||||
* `localhost/<profile_name>` to apply the profile loaded on the host with the name `<profile_name>`
|
||||
* `unconfined` to indicate that no profiles will be loaded -->
|
||||
* `unconfined` to indicate that no profiles will be loaded
|
||||
-->
|
||||
* `runtime/default` 应用运行时的默认配置
|
||||
* `localhost/<profile_name>` 应用在名为 `<profile_name>` 的主机上加载的配置文件
|
||||
* `localhost/<profile_name>` 应用在主机上加载的名为 `<profile_name>` 的配置文件
|
||||
* `unconfined` 表示不加载配置文件
|
||||
|
||||
<!-- See the [API Reference](#api-reference) for the full details on the annotation and profile name formats. -->
|
||||
有关注释和配置文件名称格式的详细信息，请参阅[API 参考](#api-reference)。
|
||||
<!--
|
||||
See the [API Reference](#api-reference) for the full details on the annotation and profile name formats.
|
||||
-->
|
||||
有关注解和配置文件名称格式的详细信息，请参阅[API 参考](#api-reference)。
|
||||
|
||||
<!-- Kubernetes AppArmor enforcement works by first checking that all the prerequisites have been
|
||||
<!--
|
||||
Kubernetes AppArmor enforcement works by first checking that all the prerequisites have been
|
||||
met, and then forwarding the profile selection to the container runtime for enforcement. If the
|
||||
prerequisites have not been met, the Pod will be rejected, and will not run. -->
|
||||
Kubernetes AppArmor 强制执行方式首先通过检查所有先决条件都已满足，然后将配置文件选择转发到容器运行时进行强制执行。如果未满足先决条件， Pod 将被拒绝，并且不会运行。
|
||||
prerequisites have not been met, the Pod will be rejected, and will not run.
|
||||
-->
|
||||
Kubernetes AppArmor 强制执行机制首先检查所有先决条件都已满足，
|
||||
然后将所选的配置文件转发到容器运行时进行强制执行。
|
||||
如果未满足先决条件，Pod 将被拒绝，并且不会运行。
|
||||
|
||||
<!-- To verify that the profile was applied, you can look for the AppArmor security option listed in the container created event: -->
|
||||
要验证是否应用了配置文件，可以查找容器创建事件中列出的 AppArmor 安全选项：
|
||||
<!--
|
||||
To verify that the profile was applied, you can look for the AppArmor security option listed in the container created event:
|
||||
-->
|
||||
要验证是否应用了配置文件，可以在容器创建事件中查找所列出的 AppArmor 安全选项：
|
||||
|
||||
```shell
|
||||
kubectl get events | grep Created
|
||||
@@ -234,8 +268,10 @@ kubectl get events | grep Created
|
||||
22s 22s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet e2e-test-stclair-node-pool-31nt} Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
|
||||
```
|
||||
|
||||
<!-- You can also verify directly that the container's root process is running with the correct profile by checking its proc attr: -->
|
||||
您还可以通过检查容器的 proc attr，直接验证容器的根进程是否以正确的配置文件运行：
|
||||
<!--
|
||||
You can also verify directly that the container's root process is running with the correct profile by checking its proc attr:
|
||||
-->
|
||||
你还可以通过检查容器的 proc attr，直接验证容器的根进程是否以正确的配置文件运行：
|
||||
|
||||
```shell
|
||||
kubectl exec <pod_name> cat /proc/1/attr/current
|
||||
@@ -245,31 +281,37 @@ k8s-apparmor-example-deny-write (enforce)
|
||||
```
|
||||
|
||||
<!-- ## Example -->
|
||||
## 举例
|
||||
## 举例 {#example}
|
||||
|
||||
<!-- *This example assumes you have already set up a cluster with AppArmor support.* -->
|
||||
*本例假设您已经使用 AppArmor 支持设置了一个集群。*
|
||||
*本例假设你已经设置了一个集群使用 AppArmor 支持。*
|
||||
|
||||
<!-- First, we need to load the profile we want to use onto our nodes. This profile denies all file writes: -->
|
||||
<!--
|
||||
First, we need to load the profile we want to use onto our nodes. This profile denies all file writes:
|
||||
-->
|
||||
首先，我们需要将要使用的配置文件加载到节点上。配置文件拒绝所有文件写入：
|
||||
|
||||
```shell
|
||||
#include <tunables/global>
|
||||
|
||||
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
|
||||
#include <abstractions/base>
|
||||
|
||||
file,
|
||||
|
||||
# Deny all file writes.
|
||||
deny /** w,
|
||||
}
|
||||
```
|
||||
|
||||
<!-- Since we don't know where the Pod will be scheduled, we'll need to load the profile on all our
|
||||
<!--
|
||||
Since we don't know where the Pod will be scheduled, we'll need to load the profile on all our
|
||||
nodes. For this example we'll use SSH to install the profiles, but other approaches are
|
||||
discussed in [Setting up nodes with profiles](#setting-up-nodes-with-profiles).
|
||||
-->
|
||||
由于我们不知道 Pod 将被调度到哪里，我们需要在所有节点上加载配置文件。
|
||||
在本例中，我们将使用 SSH 来安装概要文件，但是在[使用配置文件设置节点](#setting-up-nodes-with-profiles)
|
||||
中讨论了其他方法。
|
||||
在本例中，我们将使用 SSH 来安装概要文件，
|
||||
但是在[使用配置文件设置节点](#setting-up-nodes-with-profiles)中讨论了其他方法。
|
||||
|
||||
```shell
|
||||
NODES=(
|
||||
@@ -293,7 +335,7 @@ done
|
||||
```
|
||||
|
||||
<!-- Next, we'll run a simple "Hello AppArmor" pod with the deny-write profile: -->
|
||||
接下来，我们将运行一个带有拒绝写入配置文件的简单 "Hello AppArmor" pod：
|
||||
接下来，我们将运行一个带有拒绝写入配置文件的简单 “Hello AppArmor” Pod：
|
||||
|
||||
{{< codenew file="pods/security/hello-apparmor.yaml" >}}
|
||||
|
||||
@@ -301,9 +343,12 @@ done
|
||||
kubectl create -f ./hello-apparmor.yaml
|
||||
```
|
||||
|
||||
<!-- If we look at the pod events, we can see that the Pod container was created with the AppArmor
|
||||
profile "k8s-apparmor-example-deny-write": -->
|
||||
如果我们查看 pod 事件，我们可以看到 pod 容器是用 AppArmor 配置文件 "k8s-apparmor-example-deny-write" 所创建的：
|
||||
<!--
|
||||
If we look at the pod events, we can see that the Pod container was created with the AppArmor
|
||||
profile "k8s-apparmor-example-deny-write":
|
||||
-->
|
||||
如果我们查看 Pod 事件，我们可以看到 Pod 容器是用 AppArmor
|
||||
配置文件 “k8s-apparmor-example-deny-write” 所创建的：
|
||||
|
||||
```shell
|
||||
kubectl get events | grep hello-apparmor
|
||||
@@ -327,7 +372,7 @@ k8s-apparmor-example-deny-write (enforce)
|
||||
```
|
||||
|
||||
<!-- Finally, we can see what happens if we try to violate the profile by writing to a file: -->
|
||||
最后，我们可以看到如果试图通过写入文件来违反配置文件，会发生什么情况：
|
||||
最后，我们可以看到，如果我们尝试通过写入文件来违反配置文件会发生什么：
|
||||
|
||||
```shell
|
||||
kubectl exec hello-apparmor -- touch /tmp/test
|
||||
@@ -411,41 +456,56 @@ Events:
|
||||
23s 23s 1 {kubelet e2e-test-stclair-node-pool-t1f5} Warning AppArmor Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
|
||||
```
|
||||
|
||||
<!-- Note the pod status is Pending, with a helpful error message: `Pod Cannot enforce AppArmor: profile
|
||||
"k8s-apparmor-example-allow-write" is not loaded`. An event was also recorded with the same message. -->
|
||||
注意 pod 呈现 Pending 状态，并且显示一条有用的错误信息：`Pod Cannot enforce AppArmor: profile
|
||||
"k8s-apparmor-example-allow-write" 未加载`。还用相同的消息记录了一个事件。
|
||||
<!--
|
||||
Note the pod status is Pending, with a helpful error message: `Pod Cannot enforce AppArmor: profile
|
||||
"k8s-apparmor-example-allow-write" is not loaded`. An event was also recorded with the same message.
|
||||
-->
|
||||
注意 Pod 呈现 Pending 状态，并且显示一条有用的错误信息：
|
||||
`Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded`。
|
||||
还用相同的消息记录了一个事件。
|
||||
|
||||
<!-- ## Administration -->
|
||||
## 管理
|
||||
## 管理 {#administration}
|
||||
|
||||
<!-- ### Setting up nodes with profiles -->
|
||||
### 使用配置文件设置节点
|
||||
### 使用配置文件设置节点 {#setting-up-nodes-with-profiles}
|
||||
|
||||
<!-- Kubernetes does not currently provide any native mechanisms for loading AppArmor profiles onto
|
||||
nodes. There are lots of ways to setup the profiles though, such as: -->
|
||||
Kubernetes 目前不提供任何本地机制来将 AppArmor 配置文件加载到节点上。有很多方法可以设置配置文件，例如：
|
||||
<!--
|
||||
Kubernetes does not currently provide any native mechanisms for loading AppArmor profiles onto
|
||||
nodes. There are lots of ways to setup the profiles though, such as:
|
||||
-->
|
||||
Kubernetes 目前不提供任何本地机制来将 AppArmor 配置文件加载到节点上。
|
||||
有很多方法可以设置配置文件，例如：
|
||||
|
||||
<!-- * Through a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) that runs a Pod on each node to
|
||||
<!--
|
||||
* Through a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) that runs a Pod on each node to
|
||||
ensure the correct profiles are loaded. An example implementation can be found
|
||||
[here](https://git.k8s.io/kubernetes/test/images/apparmor-loader).
|
||||
* At node initialization time, using your node initialization scripts (e.g. Salt, Ansible, etc.) or
|
||||
image.
|
||||
* By copying the profiles to each node and loading them through SSH, as demonstrated in the
|
||||
[Example](#example). -->
|
||||
* 通过在每个节点上运行 Pod 的[DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)确保加载了正确的配置文件。可以找到一个示例实现[这里](https://git.k8s.io/kubernetes/test/images/apparmor-loader)。
|
||||
* 在节点初始化时，使用节点初始化脚本(例如 Salt 、Ansible 等)或镜像。
|
||||
[Example](#example).
|
||||
-->
|
||||
* 通过在每个节点上运行 Pod 的
|
||||
[DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)来确保加载了正确的配置文件。
|
||||
可以在[这里](https://git.k8s.io/kubernetes/test/images/apparmor-loader)找到实现示例。
|
||||
* 在节点初始化时，使用节点初始化脚本(例如 Salt、Ansible 等)或镜像。
|
||||
* 通过将配置文件复制到每个节点并通过 SSH 加载它们，如[示例](#example)。
|
||||
|
||||
<!-- The scheduler is not aware of which profiles are loaded onto which node, so the full set of profiles
|
||||
<!--
|
||||
The scheduler is not aware of which profiles are loaded onto which node, so the full set of profiles
|
||||
must be loaded onto every node. An alternative approach is to add a node label for each profile (or
|
||||
class of profiles) on the node, and use a
|
||||
[node selector](/docs/concepts/configuration/assign-pod-node/) to ensure the Pod is run on a
|
||||
node with the required profile. -->
|
||||
调度程序不知道哪些配置文件加载到哪个节点上，因此必须将全套配置文件加载到每个节点上。另一种方法是为节点上的每个配置文件(或配置文件类)添加节点标签，并使用[节点选择器](/zh/docs/concepts/configuration/assign pod node/)确保 Pod 在具有所需配置文件的节点上运行。
|
||||
node with the required profile.
|
||||
-->
|
||||
调度程序不知道哪些配置文件加载到哪个节点上，因此必须将全套配置文件加载到每个节点上。
|
||||
另一种方法是为节点上的每个配置文件（或配置文件类）添加节点标签，
|
||||
并使用[节点选择器](/zh/docs/concepts/configuration/assign-pod-node/)确保
|
||||
Pod 在具有所需配置文件的节点上运行。
|
||||
|
||||
<!-- ### Restricting profiles with the PodSecurityPolicy -->
|
||||
### 使用 PodSecurityPolicy 限制配置文件
|
||||
### 使用 PodSecurityPolicy 限制配置文件 {#restricting-profiles-with-the-podsecuritypolicy}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
@@ -456,114 +516,157 @@ PodSecurityPolicy 在 Kubernetes v1.21 版本中已被废弃，将在 v1.25 版
|
||||
查看 [PodSecurityPolicy 文档](/zh/docs/concepts/policy/pod-security-policy/)获取更多信息。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To
|
||||
enable the PodSecurityPolicy, the following flag must be set on the `apiserver`: -->
|
||||
如果启用了 PodSecurityPolicy 扩展，则可以应用群集范围的 AppArmor 限制。要启用 PodSecurityPolicy，必须在“apiserver”上设置以下标志：
|
||||
<!--
|
||||
If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To
|
||||
enable the PodSecurityPolicy, the following flag must be set on the `apiserver`:
|
||||
-->
|
||||
如果启用了 PodSecurityPolicy 扩展，则可以应用群集范围的 AppArmor 限制。
|
||||
要启用 PodSecurityPolicy，必须在 `apiserver` 上设置以下标志：
|
||||
|
||||
```
|
||||
--enable-admission-plugins=PodSecurityPolicy[,others...]
|
||||
```
|
||||
|
||||
<!-- The AppArmor options can be specified as annotations on the PodSecurityPolicy: -->
|
||||
AppArmor 选项可以指定为 PodSecurityPolicy 上的注释：
|
||||
AppArmor 选项可以指定为 PodSecurityPolicy 上的注解：
|
||||
|
||||
```yaml
|
||||
apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
|
||||
apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...]
|
||||
```
|
||||
|
||||
<!-- The default profile name option specifies the profile to apply to containers by default when none is
|
||||
<!--
|
||||
The default profile name option specifies the profile to apply to containers by default when none is
|
||||
specified. The allowed profile names option specifies a list of profiles that Pod containers are
|
||||
allowed to be run with. If both options are provided, the default must be allowed. The profiles are
|
||||
specified in the same format as on containers. See the [API Reference](#api-reference) for the full
|
||||
specification. -->
|
||||
默认配置文件名选项指定默认情况下在未指定任何配置文件时应用于容器的配置文件。节点允许配置文件名选项指定允许 Pod 容器运行时的配置文件列表。配置文件的指定格式与容器上的相同。完整规范见[API 参考](#api-reference)。
|
||||
specification.
|
||||
-->
|
||||
默认配置文件名选项指定默认情况下在未指定任何配置文件时应用于容器的配置文件。
|
||||
所允许的配置文件名称选项指定允许 Pod 容器运行期间所对应的配置文件列表。
|
||||
如果同时提供了这两个选项，则必须允许默认值。
|
||||
配置文件的指定格式与容器上的相同。有关完整规范，请参阅 [API 参考](#api-reference)。
|
||||
|
||||
<!-- ### Disabling AppArmor -->
|
||||
### 禁用 AppArmor
|
||||
### 禁用 AppArmor {#disabling-apparmor}
|
||||
|
||||
<!-- If you do not want AppArmor to be available on your cluster, it can be disabled by a command-line flag: -->
|
||||
如果您不希望 AppArmor 在集群上可用，可以通过命令行标志禁用它：
|
||||
如果你不希望 AppArmor 在集群上可用，可以通过命令行标志禁用它：
|
||||
|
||||
```
|
||||
--feature-gates=AppArmor=false
|
||||
```
|
||||
|
||||
<!-- When disabled, any Pod that includes an AppArmor profile will fail validation with a "Forbidden"
|
||||
<!--
|
||||
When disabled, any Pod that includes an AppArmor profile will fail validation with a "Forbidden"
|
||||
error. Note that by default docker always enables the "docker-default" profile on non-privileged
|
||||
pods (if the AppArmor kernel module is enabled), and will continue to do so even if the feature-gate
|
||||
is disabled. The option to disable AppArmor will be removed when AppArmor graduates to general
|
||||
availability (GA). -->
|
||||
禁用时，任何包含 AppArmor 配置文件的 Pod 都将因 "Forbidden" 错误而导致验证失败。注意，默认情况下，docker 总是在非特权 pods 上启用 "docker-default" 配置文件(如果 AppArmor 内核模块已启用)，并且即使功能门已禁用，也将继续启用该配置文件。当 AppArmor 应用于通用(GA)时，禁用 Apparmor 的选项将被删除。
|
||||
availability (GA).
|
||||
-->
|
||||
禁用时，任何包含 AppArmor 配置文件的 Pod 都将导致验证失败，且返回 “Forbidden” 错误。
|
||||
注意，默认情况下，docker 总是在非特权 Pod 上启用 “docker-default” 配置文件（如果 AppArmor 内核模块已启用），
|
||||
并且即使特性门控已禁用，也将继续启用该配置文件。
|
||||
当 AppArmor 升级到正式发布（GA）阶段时，禁用 Apparmor 的选项将被删除。
|
||||
|
||||
<!-- ### Upgrading to Kubernetes v1.4 with AppArmor -->
|
||||
### 使用 AppArmor 升级到 Kubernetes v1.4
|
||||
|
||||
<!-- No action is required with respect to AppArmor to upgrade your cluster to v1.4. However, if any
|
||||
<!--
|
||||
No action is required with respect to AppArmor to upgrade your cluster to v1.4. However, if any
|
||||
existing pods had an AppArmor annotation, they will not go through validation (or PodSecurityPolicy
|
||||
admission). If permissive profiles are loaded on the nodes, a malicious user could pre-apply a
|
||||
permissive profile to escalate the pod privileges above the docker-default. If this is a concern, it
|
||||
is recommended to scrub the cluster of any pods containing an annotation with
|
||||
`apparmor.security.beta.kubernetes.io`. -->
|
||||
不需要对 AppArmor 执行任何操作即可将集群升级到 v1.4。但是，如果任何现有的 pods 有一个 AppArmor 注释，它们将不会通过验证(或 PodSecurityPolicy 认证)。如果节点上加载了许可配置文件，恶意用户可以预先应用许可配置文件，将 pod 权限提升到 docker-default 权限之上。如果存在这个问题，建议清除包含 `apparmor.security.beta.kubernetes.io` 注释的任何 pods 的集群。
|
||||
`apparmor.security.beta.kubernetes.io`.
|
||||
-->
|
||||
不需要对 AppArmor 执行任何操作即可将集群升级到 v1.4。但是，
|
||||
如果任何现有的 Pod 有一个 AppArmor 注解，
|
||||
它们将无法通过合法性检查（或 PodSecurityPolicy 准入控制）。
|
||||
如果节点上加载了宽松的配置文件，恶意用户可以预先应用宽松的配置文件，
|
||||
将 Pod 权限提升到 docker-default 权限之上。
|
||||
如果存在这个问题，建议清除集群中包含 `apparmor.security.beta.kubernetes.io` 注解的所有 Pod。
|
||||
|
||||
<!-- ### Upgrade path to General Availability -->
|
||||
### 升级到一般可用性的途径
|
||||
### 升级到正式发布的途径 {#upgrade-path-to-general-availability}
|
||||
|
||||
<!-- When AppArmor is ready to be graduated to general availability (GA), the options currently specified
|
||||
<!--
|
||||
When AppArmor is ready to be graduated to general availability (GA), the options currently specified
|
||||
through annotations will be converted to fields. Supporting all the upgrade and downgrade paths
|
||||
through the transition is very nuanced, and will be explained in detail when the transition
|
||||
occurs. We will commit to supporting both fields and annotations for at least 2 releases, and will
|
||||
explicitly reject the annotations for at least 2 releases after that. -->
|
||||
当 Apparmor 准备升级到通用(GA)时，当前指定的选项通过注释将转换为字段。通过转换支持所有升级和降级路径是非常微妙的，并将在转换发生时详细解释。我们将承诺在至少两个版本中同时支持字段和注释，并在之后的至少两个版本中显式拒绝注释。
|
||||
explicitly reject the annotations for at least 2 releases after that.
|
||||
-->
|
||||
当 Apparmor 准备升级到正式发布（GA）状态时，当前通过注解指定的选项将转换为字段。
|
||||
通过转换支持所有升级和降级路径是非常微妙的，并将在转换发生时详细解释。
|
||||
我们将承诺在至少两个发行版本中同时支持字段和注解，并在之后的至少两个版本中显式拒绝注解。
|
||||
|
||||
<!-- ## Authoring Profiles -->
|
||||
## 编写配置文件
|
||||
## 编写配置文件 {#authoring-profiles}
|
||||
|
||||
<!-- Getting AppArmor profiles specified correctly can be a tricky business. Fortunately there are some
|
||||
tools to help with that: -->
|
||||
获得正确指定的 AppArmor 配置文件可能是一件棘手的事情。幸运的是，有一些工具可以帮助您做到这一点：
|
||||
<!--
|
||||
Getting AppArmor profiles specified correctly can be a tricky business. Fortunately there are some
|
||||
tools to help with that:
|
||||
-->
|
||||
获得正确指定的 AppArmor 配置文件可能是一件棘手的事情。幸运的是，有一些工具可以帮助你做到这一点：
|
||||
|
||||
<!-- * `aa-genprof` and `aa-logprof` generate profile rules by monitoring an application's activity and
|
||||
<!--
|
||||
* `aa-genprof` and `aa-logprof` generate profile rules by monitoring an application's activity and
|
||||
logs, and admitting the actions it takes. Further instructions are provided by the
|
||||
[AppArmor documentation](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools).
|
||||
* [bane](https://github.com/jfrazelle/bane) is an AppArmor profile generator for Docker that uses a
|
||||
simplified profile language. -->
|
||||
* `aa-genprof` and `aa-logprof` 通过监视应用程序的活动和日志并承认它所采取的操作来生成配置文件规则。更多说明由[AppArmor 文档](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools)提供。
|
||||
* [bane](https://github.com/jfrazelle/bane)是一个用于 Docker的 AppArmor 档案生成器，它使用简化的档案语言。
|
||||
simplified profile language.
|
||||
-->
|
||||
* `aa-genprof` 和 `aa-logprof`
|
||||
通过监视应用程序的活动和日志并准许它所执行的操作来生成配置文件规则。
|
||||
[AppArmor 文档](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools)提供了进一步的指导。
|
||||
* [bane](https://github.com/jfrazelle/bane)
|
||||
是一个用于 Docker的 AppArmor 配置文件生成器，它使用一种简化的画像语言（profile language）
|
||||
|
||||
<!-- It is recommended to run your application through Docker on a development workstation to generate
|
||||
<!--
|
||||
It is recommended to run your application through Docker on a development workstation to generate
|
||||
the profiles, but there is nothing preventing running the tools on the Kubernetes node where your
|
||||
Pod is running. -->
|
||||
建议在开发工作站上通过 Docker 运行应用程序以生成配置文件，但是没有什么可以阻止在运行 Pod 的 Kubernetes 节点上运行工具。
|
||||
Pod is running.
|
||||
-->
|
||||
建议在开发工作站上通过 Docker 运行应用程序以生成配置文件，
|
||||
不过在运行 Pod 的 Kubernetes 节点上运行这些工具也是可以的。
|
||||
|
||||
<!-- To debug problems with AppArmor, you can check the system logs to see what, specifically, was
|
||||
<!--
|
||||
To debug problems with AppArmor, you can check the system logs to see what, specifically, was
|
||||
denied. AppArmor logs verbose messages to `dmesg`, and errors can usually be found in the system
|
||||
logs or through `journalctl`. More information is provided in
|
||||
[AppArmor failures](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures). -->
|
||||
想要调试 AppArmor 的问题，您可以检查系统日志，查看具体拒绝了什么。AppArmor 将详细消息记录到 `dmesg` ，错误通常可以在系统日志中或通过 `journalctl` 找到。更多详细信息见[AppArmor 失败](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)。
|
||||
[AppArmor failures](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures).
|
||||
-->
|
||||
想要调试 AppArmor 的问题，你可以检查系统日志，查看具体拒绝了什么。
|
||||
AppArmor 将详细消息记录到 `dmesg`，
|
||||
错误通常可以在系统日志中或通过 `journalctl` 找到。
|
||||
更多详细信息见 [AppArmor 失败](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)。
|
||||
|
||||
<!-- ## API Reference -->
|
||||
## API 参考
|
||||
## API 参考 {#api-reference}
|
||||
|
||||
<!-- ### Pod Annotation -->
|
||||
### Pod 注释
|
||||
### Pod 注解 {#pod-annotation}
|
||||
|
||||
<!-- Specifying the profile a container will run with: -->
|
||||
指定容器将使用的配置文件：
|
||||
|
||||
<!-- - **key**: `container.apparmor.security.beta.kubernetes.io/<container_name>`
|
||||
<!--
|
||||
- **key**: `container.apparmor.security.beta.kubernetes.io/<container_name>`
|
||||
Where `<container_name>` matches the name of a container in the Pod.
|
||||
A separate profile can be specified for each container in the Pod.
|
||||
- **value**: a profile reference, described below -->
|
||||
- **key**: `container.apparmor.security.beta.kubernetes.io/<container_name>` 中的 `<container_name>` 匹配 Pod 中的容器名称。
|
||||
- **value**: a profile reference, described below
|
||||
-->
|
||||
- **键名**: `container.apparmor.security.beta.kubernetes.io/<container_name>`
|
||||
，其中 `<container_name>` 与 Pod 中某容器的名称匹配。
|
||||
可以为 Pod 中的每个容器指定单独的配置文件。
|
||||
- **value**: 配置文件参考，如下所述
|
||||
- **键值**: 对配置文件的引用，如下所述
|
||||
|
||||
<!-- ### Profile Reference -->
|
||||
### 配置文件参考
|
||||
### 配置文件引用 {#profile-reference}
|
||||
|
||||
<!-- - `runtime/default`: Refers to the default runtime profile.
|
||||
<!--
|
||||
- `runtime/default`: Refers to the default runtime profile.
|
||||
- Equivalent to not specifying a profile (without a PodSecurityPolicy default), except it still
|
||||
requires AppArmor to be enabled.
|
||||
- For Docker, this resolves to the
|
||||
@@ -572,50 +675,54 @@ logs or through `journalctl`. More information is provided in
|
||||
- `localhost/<profile_name>`: Refers to a profile loaded on the node (localhost) by name.
|
||||
- The possible profile names are detailed in the
|
||||
[core policy reference](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications).
|
||||
- `unconfined`: This effectively disables AppArmor on the container. -->
|
||||
- `unconfined`: This effectively disables AppArmor on the container.
|
||||
-->
|
||||
- `runtime/default`: 指默认运行时配置文件。
|
||||
- 等同于不指定配置文件(没有 PodSecurityPolicy 默认值)，除非它仍然需要启用 AppArmor。
|
||||
- 对于 Docker，这将解析为非特权容器的[`Docker default`](https://docs.docker.com/engine/security/apparmor/)配置文件，特权容器的配置文件为未定义(无配置文件)。
|
||||
- `localhost/<profile_name>`: 指按名称加载到节点(localhost)上的配置文件。
|
||||
- 可能的配置文件名在 [核心策略参考](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)。
|
||||
- `unconfined`: 这有效地禁用了容器上的 AppArmor 。
|
||||
- 等同于不指定配置文件（没有 PodSecurityPolicy 默认值），只是它仍然需要启用 AppArmor。
|
||||
- 对于 Docker，针对非特权容器时解析为
|
||||
[`Docker default`](https://docs.docker.com/engine/security/apparmor/) 配置文件，
|
||||
针对特权容器时解析为 unconfined（无配置文件）。
|
||||
- `localhost/<profile_name>`: 按名称引用加载到节点（localhost）上的配置文件。
|
||||
- 可能的配置文件名在[核心策略参考](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)。
|
||||
- `unconfined`: 这相当于为容器禁用 AppArmor。
|
||||
|
||||
<!-- Any other profile reference format is invalid. -->
|
||||
任何其他配置文件引用格式无效。
|
||||
|
||||
<!-- ### PodSecurityPolicy Annotations -->
|
||||
### PodSecurityPolicy 注解
|
||||
### PodSecurityPolicy 注解 {#podsecuritypolicy-annotations}
|
||||
|
||||
<!-- Specifying the default profile to apply to containers when none is provided: -->
|
||||
指定在未提供容器时应用于容器的默认配置文件：
|
||||
|
||||
<!-- * **key**: `apparmor.security.beta.kubernetes.io/defaultProfileName`
|
||||
* **value**: a profile reference, described above -->
|
||||
<!--
|
||||
* **key**: `apparmor.security.beta.kubernetes.io/defaultProfileName`
|
||||
* **value**: 如上述文件参考所述
|
||||
* **value**: a profile reference, described above
|
||||
-->
|
||||
* **键名**: `apparmor.security.beta.kubernetes.io/defaultProfileName`
|
||||
* **键值**: 如上述文件参考所述
|
||||
|
||||
<!-- Specifying the list of profiles Pod containers is allowed to specify: -->
|
||||
上面描述的指定配置文件， Pod 容器列表的配置文件引用允许指定：
|
||||
上面描述的指定配置文件，Pod 容器列表的配置文件引用允许指定：
|
||||
|
||||
<!-- * **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
|
||||
<!--
|
||||
* **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
|
||||
* **value**: a comma-separated list of profile references (described above)
|
||||
- Although an escaped comma is a legal character in a profile name, it cannot be explicitly
|
||||
allowed here. -->
|
||||
* **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
|
||||
* **value**: 配置文件引用的逗号分隔列表(如上所述)
|
||||
allowed here.
|
||||
-->
|
||||
* **键名**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
|
||||
* **键值**: 配置文件引用的逗号分隔列表（如上所述）
|
||||
- 尽管转义逗号是配置文件名中的合法字符，但此处不能显式允许。
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!-- Additional resources: -->
|
||||
其他资源
|
||||
其他资源：
|
||||
|
||||
<!-- * [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage)
|
||||
* [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout) -->
|
||||
<!--
|
||||
* [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage)
|
||||
* [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout)
|
||||
-->
|
||||
* [Apparmor 配置文件语言快速指南](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage)
|
||||
* [Apparmor 核心策略参考](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout)
|
||||
|
||||
|
||||
@@ -215,7 +215,7 @@ The StatefulSet controller creates three Pods, and each Pod has a container with
|
||||
a [ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) server.
|
||||
-->
|
||||
StatefulSet 控制器创建 3 个 Pods，每个 Pod 包含一个
|
||||
[ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) 服务器。
|
||||
[ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) 服务容器。
|
||||
|
||||
<!--
|
||||
### Facilitating Leader Election
|
||||
@@ -670,10 +670,10 @@ The `volumeMounts` section of the `StatefulSet`'s container `template` mounts th
|
||||
StatefulSet 的容器 `template` 中的 `volumeMounts` 一节使得
|
||||
PersistentVolumes 被挂载到 ZooKeeper 服务器的数据目录。
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
volumeMounts:
|
||||
- name: datadir
|
||||
mountPath: /var/lib/zookeeper
|
||||
- name: datadir
|
||||
mountPath: /var/lib/zookeeper
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -682,7 +682,7 @@ same `PersistentVolume` mounted to the ZooKeeper server's data directory.
|
||||
Even when the Pods are rescheduled, all the writes made to the ZooKeeper
|
||||
servers' WALs, and all their snapshots, remain durable.
|
||||
-->
|
||||
当 `zk` StatefulSet 中的一个 Pod 被（重新）调度时，它总是拥有相同的 PersistentVolume，
|
||||
当 `zk` `StatefulSet` 中的一个 Pod 被（重新）调度时，它总是拥有相同的 PersistentVolume，
|
||||
挂载到 ZooKeeper 服务器的数据目录。
|
||||
即使在 Pods 被重新调度时，所有对 ZooKeeper 服务器的 WALs 的写入和它们的
|
||||
全部快照都仍然是持久的。
|
||||
@@ -1110,17 +1110,17 @@ The Pod `template` for the `zk` `StatefulSet` specifies a liveness probe.
|
||||
许多场景下，一个系统进程可以是活动状态但不响应请求，或者是不健康状态。
|
||||
你应该使用存活性探针来通知 Kubernetes 你的应用进程处于不健康状态，需要被重启。
|
||||
|
||||
`zk` StatefulSet 的 Pod 的 `template` 一节指定了一个存活探针。
|
||||
`zk` `StatefulSet` 的 Pod 的 `template` 一节指定了一个存活探针。
|
||||
|
||||
```yaml
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- "zookeeper-ready 2181"
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 5
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- "zookeeper-ready 2181"
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 5
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -1249,7 +1249,7 @@ By default, Kubernetes may co-locate Pods in a `StatefulSet` on the same node.
|
||||
For the three server ensemble you created, if two servers are on the same node, and that node fails,
|
||||
the clients of your ZooKeeper service will experience an outage until at least one of the Pods can be rescheduled.
|
||||
-->
|
||||
默认情况下，Kubernetes 可以把 StatefulSet 的 Pods 部署在相同节点上。
|
||||
默认情况下，Kubernetes 可以把 `StatefulSet` 的 Pods 部署在相同节点上。
|
||||
对于你创建的 3 个服务器的 ensemble 来说，如果有两个服务器并存于
|
||||
相同的节点上并且该节点发生故障时，ZooKeeper 服务将中断，
|
||||
直至至少一个 Pods 被重新调度。
|
||||
@@ -1268,7 +1268,7 @@ Use the command below to get the nodes for Pods in the `zk` `StatefulSet`.
|
||||
ZooKeeper 服务器为止。
|
||||
但是，如果希望你的服务在容忍节点故障时无停服时间，你应该设置 `podAntiAffinity`。
|
||||
|
||||
获取 `zk` Stateful Set 中的 Pods 的节点。
|
||||
使用下面的命令获取 `zk` `StatefulSet` 中的 Pods 的节点。
|
||||
|
||||
```shell
|
||||
for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
|
||||
@@ -1450,7 +1450,7 @@ zk-0 1/1 Running 0 1m
|
||||
Keep watching the `StatefulSet`'s Pods in the first terminal and drain the node on which
|
||||
`zk-1` is scheduled.
|
||||
-->
|
||||
在第一个终端中持续观察 StatefulSet 的 Pods 并腾空 `zk-1` 调度所在的节点。
|
||||
在第一个终端中持续观察 `StatefulSet` 的 Pods 并腾空 `zk-1` 调度所在的节点。
|
||||
|
||||
```shell
|
||||
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force -delete-emptydir-data "kubernetes-node-ixsl" cordoned
|
||||
@@ -1467,7 +1467,7 @@ The `zk-1` Pod cannot be scheduled because the `zk` `StatefulSet` contains a `Po
|
||||
co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state.
|
||||
-->
|
||||
`zk-1` Pod 不能被调度，这是因为 `zk` `StatefulSet` 包含了一个防止 Pods
|
||||
共存的 PodAntiAffinity 规则，而且只有两个节点可用于调度，
|
||||
共存的 `PodAntiAffinity` 规则，而且只有两个节点可用于调度，
|
||||
这个 Pod 将保持在 Pending 状态。
|
||||
|
||||
```shell
|
||||
@@ -1498,7 +1498,7 @@ zk-1 0/1 Pending 0 0s
|
||||
```
|
||||
|
||||
<!--
|
||||
Continue to watch the Pods of the stateful set, and drain the node on which
|
||||
Continue to watch the Pods of the StatefulSet, and drain the node on which
|
||||
`zk-2` is scheduled.
|
||||
-->
|
||||
继续观察 StatefulSet 中的 Pods 并腾空 `zk-2` 调度所在的节点。
|
||||
@@ -1522,7 +1522,7 @@ You cannot drain the third node because evicting `zk-2` would violate `zk-budget
|
||||
|
||||
Use `zkCli.sh` to retrieve the value you entered during the sanity test from `zk-0`.
|
||||
-->
|
||||
使用 `CRTL-C` 终止 kubectl。
|
||||
使用 `CTRL-C` 终止 kubectl。
|
||||
|
||||
你不能腾空第三个节点，因为驱逐 `zk-2` 将和 `zk-budget` 冲突。
|
||||
然而这个节点仍然处于隔离状态（Cordoned）。
|
||||
@@ -1536,7 +1536,7 @@ kubectl exec zk-0 zkCli.sh get /hello
|
||||
<!--
|
||||
The service is still available because its `PodDisruptionBudget` is respected.
|
||||
-->
|
||||
由于遵守了 PodDisruptionBudget，服务仍然可用。
|
||||
由于遵守了 `PodDisruptionBudget`，服务仍然可用。
|
||||
|
||||
```
|
||||
WatchedEvent state:SyncConnected type:None path:null
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user