Kubernetes Prow Robot
GitHub
commit
ebd7ff0b64
|
|
@ -0,0 +1,137 @@
|
|||
---
|
||||
layout: blog
|
||||
title: 'Kubernetes Removals and Major Changes In v1.31'
|
||||
date: 2024-07-19
|
||||
slug: kubernetes-1-31-upcoming-changes
|
||||
author: >
|
||||
Abigail McCarthy,
|
||||
Edith Puclla,
|
||||
Matteo Bianchi,
|
||||
Rashan Smith,
|
||||
Yigit Demirbas
|
||||
---
|
||||
|
||||
As Kubernetes develops and matures, features may be deprecated, removed, or replaced with better ones for the project's overall health.
|
||||
This article outlines some planned changes for the Kubernetes v1.31 release that the release team feels you should be aware of for the continued maintenance of your Kubernetes environment.
|
||||
The information listed below is based on the current status of the v1.31 release.
|
||||
It may change before the actual release date.
|
||||
|
||||
## The Kubernetes API removal and deprecation process
|
||||
The Kubernetes project has a well-documented [deprecation policy](/docs/reference/using-api/deprecation-policy/) for features.
|
||||
This policy states that stable APIs may only be deprecated when a newer, stable version of that API is available and that APIs have a minimum lifetime for each stability level.
|
||||
A deprecated API has been marked for removal in a future Kubernetes release.
|
||||
It will continue to function until removal (at least one year from the deprecation), but usage will display a warning.
|
||||
Removed APIs are no longer available in the current version, so you must migrate to using the replacement.
|
||||
|
||||
* Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes.
|
||||
|
||||
* Beta or pre-release API versions must be supported for 3 releases after the deprecation.
|
||||
|
||||
* Alpha or experimental API versions may be removed in any release without prior deprecation notice.
|
||||
|
||||
Whether an API is removed because a feature graduated from beta to stable or because that API did not succeed, all removals comply with this deprecation policy.
|
||||
Whenever an API is removed, migration options are communicated in the [documentation](/docs/reference/using-api/deprecation-guide/).
|
||||
|
||||
## A note about SHA-1 signature support
|
||||
|
||||
In [go1.18](https://go.dev/doc/go1.18#sha1) (released in March 2022), the crypto/x509 library started to reject certificates signed with a SHA-1 hash function.
|
||||
While SHA-1 is established to be unsafe and publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015, there might still be cases in the context of Kubernetes where user-provided certificates are signed using a SHA-1 hash function through private authorities with them being used for Aggregated API Servers or webhooks.
|
||||
If you have relied on SHA-1 based certificates, you must explicitly opt back into its support by setting `GODEBUG=x509sha1=1` in your environment.
|
||||
|
||||
Given Go's [compatibility policy for GODEBUGs](https://go.dev/blog/compat), the `x509sha1` GODEBUG and the support for SHA-1 certificates will [fully go away in go1.24](https://tip.golang.org/doc/go1.23) which will be released in the first half of 2025.
|
||||
If you rely on SHA-1 certificates, please start moving off them.
|
||||
|
||||
Please see [Kubernetes issue #125689](https://github.com/kubernetes/kubernetes/issues/125689) to get a better idea of timelines around the support for SHA-1 going away, when Kubernetes releases plans to adopt go1.24, and for more details on how to detect usage of SHA-1 certificates via metrics and audit logging.
|
||||
|
||||
## Deprecations and removals in Kubernetes 1.31
|
||||
|
||||
|
||||
### Deprecation of `status.nodeInfo.kubeProxyVersion` field for Nodes ([KEP 4004](https://github.com/kubernetes/enhancements/issues/4004))
|
||||
|
||||
The `.status.nodeInfo.kubeProxyVersion` field of Nodes is being deprecated in Kubernetes v1.31,
|
||||
and will be removed in a later release.
|
||||
It's being deprecated because the value of this field wasn't (and isn't) accurate.
|
||||
This field is set by the kubelet, which does not have reliable information about the kube-proxy version or whether kube-proxy is running.
|
||||
|
||||
The `DisableNodeKubeProxyVersion` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) will be set to `true` in by default in v1.31 and the kubelet will no longer attempt to set the `.status.kubeProxyVersion` field for its associated Node.
|
||||
|
||||
### Removal of all in-tree integrations with cloud providers
|
||||
|
||||
As highlighted in a [previous article](/blog/2024/05/20/completing-cloud-provider-migration/), the last remaining in-tree support for cloud provider integration will be removed as part of the v1.31 release.
|
||||
This doesn't mean you can't integrate with a cloud provider, however you now **must** use the
|
||||
recommended approach using an external integration. Some integrations are part of the Kubernetes
|
||||
project and others are third party software.
|
||||
|
||||
This milestone marks the completion of the externalization process for all cloud providers' integrations from the Kubernetes core ([KEP-2395](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cloud-provider/2395-removing-in-tree-cloud-providers/README.md)), a process started with Kubernetes v1.26.
|
||||
This change helps Kubernetes to get closer to being a truly vendor-neutral platform.
|
||||
|
||||
For further details on the cloud provider integrations, read our [v1.29 Cloud Provider Integrations feature blog](/blog/2023/12/14/cloud-provider-integration-changes/).
|
||||
For additional context about the in-tree code removal, we invite you to check the ([v1.29 deprecation blog](/blog/2023/11/16/kubernetes-1-29-upcoming-changes/#removal-of-in-tree-integrations-with-cloud-providers-kep-2395-https-kep-k8s-io-2395)).
|
||||
|
||||
The latter blog also contains useful information for users who need to migrate to version v1.29 and later.
|
||||
|
||||
|
||||
### Removal of kubelet `--keep-terminated-pod-volumes` command line flag
|
||||
|
||||
The kubelet flag `--keep-terminated-pod-volumes`, which was deprecated in 2017, will be removed as
|
||||
part of the v1.31 release.
|
||||
|
||||
You can find more details in the pull request [#122082](https://github.com/kubernetes/kubernetes/pull/122082).
|
||||
|
||||
### Removal of CephFS volume plugin
|
||||
|
||||
[CephFS volume plugin](/docs/concepts/storage/volumes/#cephfs) was removed in this release and the `cephfs` volume type became non-functional.
|
||||
|
||||
It is recommended that you use the [CephFS CSI driver](https://github.com/ceph/ceph-csi/) as a third-party storage driver instead. If you were using the CephFS volume plugin before upgrading the cluster version to v1.31, you must re-deploy your application to use the new driver.
|
||||
|
||||
CephFS volume plugin was formally marked as deprecated in v1.28.
|
||||
|
||||
### Removal of Ceph RBD volume plugin
|
||||
|
||||
The v1.31 release will remove the [Ceph RBD volume plugin](/docs/concepts/storage/volumes/#rbd) and its CSI migration support, making the `rbd` volume type non-functional.
|
||||
|
||||
It's recommended that you use the [RBD CSI driver](https://github.com/ceph/ceph-csi/) in your clusters instead.
|
||||
If you were using Ceph RBD volume plugin before upgrading the cluster version to v1.31, you must re-deploy your application to use the new driver.
|
||||
|
||||
The Ceph RBD volume plugin was formally marked as deprecated in v1.28.
|
||||
|
||||
### Deprecation of non-CSI volume limit plugins in kube-scheduler
|
||||
|
||||
The v1.31 release will deprecate all non-CSI volume limit scheduler plugins, and will remove some
|
||||
already deprected plugins from the [default plugins](/docs/reference/scheduling/config/), including:
|
||||
|
||||
- `AzureDiskLimits`
|
||||
- `CinderLimits`
|
||||
- `EBSLimits`
|
||||
- `GCEPDLimits`
|
||||
|
||||
It's recommended that you use the `NodeVolumeLimits` plugin instead because it can handle the same functionality as the removed plugins since those volume types have been migrated to CSI.
|
||||
Please replace the deprecated plugins with the `NodeVolumeLimits` plugin if you explicitly use them in the [scheduler config](/docs/reference/scheduling/config/).
|
||||
The `AzureDiskLimits`, `CinderLimits`, `EBSLimits`, and `GCEPDLimits` plugins will be removed in a future release.
|
||||
|
||||
These plugins will be removed from the default scheduler plugins list as they have been deprecated since Kubernetes v1.14.
|
||||
|
||||
## Looking ahead
|
||||
The official list of API removals planned for [Kubernetes v1.32](/docs/reference/using-api/deprecation-guide/#v1-32) include:
|
||||
|
||||
* The `flowcontrol.apiserver.k8s.io/v1beta3` API version of FlowSchema and PriorityLevelConfiguration will be removed.
|
||||
To prepare for this, you can edit your existing manifests and rewrite client software to use the `flowcontrol.apiserver.k8s.io/v1 API` version, available since v1.29.
|
||||
All existing persisted objects are accessible via the new API. Notable changes in flowcontrol.apiserver.k8s.io/v1beta3 include that the PriorityLevelConfiguration `spec.limited.nominalConcurrencyShares` field only defaults to 30 when unspecified, and an explicit value of 0 is not changed to 30.
|
||||
|
||||
For more information, please refer to the [API deprecation guide](/docs/reference/using-api/deprecation-guide/#v1-32).
|
||||
|
||||
## Want to know more?
|
||||
The Kubernetes release notes announce deprecations.
|
||||
We will formally announce the deprecations in [Kubernetes v1.31](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md#deprecation) as part of the CHANGELOG for that release.
|
||||
|
||||
You can see the announcements of pending deprecations in the release notes for:
|
||||
|
||||
* [Kubernetes v1.30](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md#deprecation)
|
||||
|
||||
* [Kubernetes v1.29](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#deprecation)
|
||||
|
||||
* [Kubernetes v1.28](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.28.md#deprecation)
|
||||
|
||||
* [Kubernetes v1.27](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md#deprecation)
|
||||
|
||||
|
||||
|
|
@ -31,7 +31,8 @@ There is also experimental (alpha) support for distributing [trust bundles](#clu
|
|||
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
|
||||
|
||||
|
||||
A CertificateSigningRequest (CSR) resource is used to request that a certificate be signed
|
||||
A [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
|
||||
(CSR) resource is used to request that a certificate be signed
|
||||
by a denoted signer, after which the request may be approved or denied before
|
||||
finally being signed.
|
||||
|
||||
|
|
@ -171,7 +172,7 @@ Kubernetes provides built-in signers that each have a well-known `signerName`:
|
|||
May be auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
|
||||
1. Trust distribution: signed certificates must be honored as client certificates by the API server. The CA bundle
|
||||
is not distributed by any other means.
|
||||
1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name starts with "`system:node:`".
|
||||
1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name is "`system:node:${NODE_NAME}`".
|
||||
1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions and drops other extensions.
|
||||
1. Permitted key usages - `["key encipherment", "digital signature", "client auth"]` or `["digital signature", "client auth"]`.
|
||||
1. Expiration/certificate lifetime - for the kube-controller-manager implementation of this signer, set to the minimum
|
||||
|
|
@ -183,7 +184,7 @@ Kubernetes provides built-in signers that each have a well-known `signerName`:
|
|||
Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
|
||||
1. Trust distribution: signed certificates must be honored by the API server as valid to terminate connections to a kubelet.
|
||||
The CA bundle is not distributed by any other means.
|
||||
1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name starts with "`system:node:`".
|
||||
1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name is "`system:node:${NODE_NAME}`".
|
||||
1. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and
|
||||
URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present.
|
||||
1. Permitted key usages - `["key encipherment", "digital signature", "server auth"]` or `["digital signature", "server auth"]`.
|
||||
|
|
@ -505,7 +506,9 @@ openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"
|
|||
|
||||
### Create a CertificateSigningRequest {#create-certificatessigningrequest}
|
||||
|
||||
Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest.
|
||||
Create a [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
|
||||
and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the
|
||||
CertificateSigningRequest.
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl apply -f -
|
||||
|
|
|
|||
|
|
@ -1018,6 +1018,21 @@ to record the version of Windows Server in use.
|
|||
|
||||
The label's value is in the format "MajorVersion.MinorVersion.BuildNumber".
|
||||
|
||||
### storage.alpha.kubernetes.io/migrated-plugins {#storagealphakubernetesiomigrated-plugins}
|
||||
|
||||
Type: Annotation
|
||||
|
||||
Example:`storage.alpha.kubernetes.io/migrated-plugins: "kubernetes.io/cinder"`
|
||||
|
||||
Used on: CSINode (an extension API)
|
||||
|
||||
This annotation is automatically added for the CSINode object that maps to a node that
|
||||
installs CSIDriver. This annotation shows the in-tree plugin name of the migrated plugin. Its
|
||||
value depends on your cluster's in-tree cloud provider storage type.
|
||||
|
||||
For example, if the in-tree cloud provider storage type is `CSIMigrationvSphere`, the CSINodes instance for the node should be updated with:
|
||||
`storage.alpha.kubernetes.io/migrated-plugins: "kubernetes.io/vsphere-volume"`
|
||||
|
||||
### service.kubernetes.io/headless {#servicekubernetesioheadless}
|
||||
|
||||
Type: Label
|
||||
|
|
|
|||
|
|
@ -165,7 +165,7 @@ spec:
|
|||
image: nginx
|
||||
```
|
||||
|
||||
This pod runs in the `BestEffort` QoS class because no resource `requests` or
|
||||
The pod above runs in the `BestEffort` QoS class because no resource `requests` or
|
||||
`limits` are specified. It runs in the shared pool.
|
||||
|
||||
```yaml
|
||||
|
|
@ -180,7 +180,7 @@ spec:
|
|||
memory: "100Mi"
|
||||
```
|
||||
|
||||
This pod runs in the `Burstable` QoS class because resource `requests` do not
|
||||
The pod above runs in the `Burstable` QoS class because resource `requests` do not
|
||||
equal `limits` and the `cpu` quantity is not specified. It runs in the shared
|
||||
pool.
|
||||
|
||||
|
|
@ -198,7 +198,7 @@ spec:
|
|||
cpu: "1"
|
||||
```
|
||||
|
||||
This pod runs in the `Burstable` QoS class because resource `requests` do not
|
||||
The pod above runs in the `Burstable` QoS class because resource `requests` do not
|
||||
equal `limits`. It runs in the shared pool.
|
||||
|
||||
```yaml
|
||||
|
|
@ -215,7 +215,7 @@ spec:
|
|||
cpu: "2"
|
||||
```
|
||||
|
||||
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
The pod above runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
And the container's resource limit for the CPU resource is an integer greater than
|
||||
or equal to one. The `nginx` container is granted 2 exclusive CPUs.
|
||||
|
||||
|
|
@ -234,7 +234,7 @@ spec:
|
|||
cpu: "1.5"
|
||||
```
|
||||
|
||||
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
The pod above runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
But the container's resource limit for the CPU resource is a fraction. It runs in
|
||||
the shared pool.
|
||||
|
||||
|
|
@ -250,7 +250,7 @@ spec:
|
|||
cpu: "2"
|
||||
```
|
||||
|
||||
This pod runs in the `Guaranteed` QoS class because only `limits` are specified
|
||||
The pod above runs in the `Guaranteed` QoS class because only `limits` are specified
|
||||
and `requests` are set equal to `limits` when not explicitly specified. And the
|
||||
container's resource limit for the CPU resource is an integer greater than or
|
||||
equal to one. The `nginx` container is granted 2 exclusive CPUs.
|
||||
|
|
|
|||
|
|
@ -21,14 +21,14 @@ generates a Secret that you can apply to the API server using `kubectl`.
|
|||
|
||||
You can generate a Secret by defining a `secretGenerator` in a
|
||||
`kustomization.yaml` file that references other existing files, `.env` files, or
|
||||
literal values. For example, the following instructions create a Kustomization
|
||||
literal values. For example, the following instructions create a kustomization
|
||||
file for the username `admin` and the password `1f2d1e2e67df`.
|
||||
|
||||
{{< note >}}
|
||||
The `stringData` field for a Secret does not work well with server-side apply.
|
||||
{{< /note >}}
|
||||
|
||||
### Create the Kustomization file
|
||||
### Create the kustomization file
|
||||
|
||||
{{< tabs name="Secret data" >}}
|
||||
{{< tab name="Literals" codelang="yaml" >}}
|
||||
|
|
@ -57,7 +57,7 @@ secretGenerator:
|
|||
- username.txt
|
||||
- password.txt
|
||||
```
|
||||
{{% /tab %}}}
|
||||
{{% /tab %}}
|
||||
{{% tab name=".env files" %}}
|
||||
You can also define the secretGenerator in the `kustomization.yaml` file by
|
||||
providing `.env` files. For example, the following `kustomization.yaml` file
|
||||
|
|
@ -72,7 +72,7 @@ secretGenerator:
|
|||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
In all cases, you don't need to base64 encode the values. The name of the YAML
|
||||
In all cases, you don't need to encode the values in base64. The name of the YAML
|
||||
file **must** be `kustomization.yaml` or `kustomization.yml`.
|
||||
|
||||
### Apply the kustomization file
|
||||
|
|
@ -93,7 +93,7 @@ When a Secret is generated, the Secret name is created by hashing
|
|||
the Secret data and appending the hash value to the name. This ensures that
|
||||
a new Secret is generated each time the data is modified.
|
||||
|
||||
To verify that the Secret was created and to decode the Secret data,
|
||||
To verify that the Secret was created and to decode the Secret data,
|
||||
|
||||
```shell
|
||||
kubectl get -k <directory-path> -o jsonpath='{.data}'
|
||||
|
|
@ -102,17 +102,17 @@ kubectl get -k <directory-path> -o jsonpath='{.data}'
|
|||
The output is similar to:
|
||||
|
||||
```
|
||||
{ "password": "UyFCXCpkJHpEc2I9", "username": "YWRtaW4=" }
|
||||
{ "password": "MWYyZDFlMmU2N2Rm", "username": "YWRtaW4=" }
|
||||
```
|
||||
|
||||
```
|
||||
echo 'UyFCXCpkJHpEc2I9' | base64 --decode
|
||||
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
|
||||
```
|
||||
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
S!B\*d$zDsb=
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
For more information, refer to
|
||||
|
|
|
|||
|
|
@ -750,7 +750,7 @@ validations are not supported by ratcheting under the implementation in Kubernet
|
|||
- `not`
|
||||
- any validations in a descendent of one of these fields
|
||||
- `x-kubernetes-validations`
|
||||
For Kubernetes 1.28, CRD validation rules](#validation-rules) are ignored by
|
||||
For Kubernetes 1.28, CRD [validation rules](#validation-rules) are ignored by
|
||||
ratcheting. Starting with Alpha 2 in Kubernetes 1.29, `x-kubernetes-validations`
|
||||
are ratcheted only if they do not refer to `oldSelf`.
|
||||
|
||||
|
|
@ -1630,6 +1630,45 @@ my-new-cron-object * * * * * 1 7s
|
|||
The `NAME` column is implicit and does not need to be defined in the CustomResourceDefinition.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
#### Priority
|
||||
|
||||
Each column includes a `priority` field. Currently, the priority
|
||||
differentiates between columns shown in standard view or wide view (using the `-o wide` flag).
|
||||
|
||||
- Columns with priority `0` are shown in standard view.
|
||||
- Columns with priority greater than `0` are shown only in wide view.
|
||||
|
||||
#### Type
|
||||
|
||||
A column's `type` field can be any of the following (compare
|
||||
[OpenAPI v3 data types](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)):
|
||||
|
||||
- `integer` – non-floating-point numbers
|
||||
- `number` – floating point numbers
|
||||
- `string` – strings
|
||||
- `boolean` – `true` or `false`
|
||||
- `date` – rendered differentially as time since this timestamp.
|
||||
|
||||
If the value inside a CustomResource does not match the type specified for the column,
|
||||
the value is omitted. Use CustomResource validation to ensure that the value
|
||||
types are correct.
|
||||
|
||||
#### Format
|
||||
|
||||
A column's `format` field can be any of the following:
|
||||
|
||||
- `int32`
|
||||
- `int64`
|
||||
- `float`
|
||||
- `double`
|
||||
- `byte`
|
||||
- `date`
|
||||
- `date-time`
|
||||
- `password`
|
||||
|
||||
The column's `format` controls the style used when `kubectl` prints the value.
|
||||
|
||||
### Field selectors
|
||||
|
||||
[Field Selectors](/docs/concepts/overview/working-with-objects/field-selectors/)
|
||||
|
|
@ -1719,44 +1758,6 @@ NAME COLOR SIZE
|
|||
example2 blue M
|
||||
```
|
||||
|
||||
#### Priority
|
||||
|
||||
Each column includes a `priority` field. Currently, the priority
|
||||
differentiates between columns shown in standard view or wide view (using the `-o wide` flag).
|
||||
|
||||
- Columns with priority `0` are shown in standard view.
|
||||
- Columns with priority greater than `0` are shown only in wide view.
|
||||
|
||||
#### Type
|
||||
|
||||
A column's `type` field can be any of the following (compare
|
||||
[OpenAPI v3 data types](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)):
|
||||
|
||||
- `integer` – non-floating-point numbers
|
||||
- `number` – floating point numbers
|
||||
- `string` – strings
|
||||
- `boolean` – `true` or `false`
|
||||
- `date` – rendered differentially as time since this timestamp.
|
||||
|
||||
If the value inside a CustomResource does not match the type specified for the column,
|
||||
the value is omitted. Use CustomResource validation to ensure that the value
|
||||
types are correct.
|
||||
|
||||
#### Format
|
||||
|
||||
A column's `format` field can be any of the following:
|
||||
|
||||
- `int32`
|
||||
- `int64`
|
||||
- `float`
|
||||
- `double`
|
||||
- `byte`
|
||||
- `date`
|
||||
- `date-time`
|
||||
- `password`
|
||||
|
||||
The column's `format` controls the style used when `kubectl` prints the value.
|
||||
|
||||
### Subresources
|
||||
|
||||
Custom resources support `/status` and `/scale` subresources.
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ Where `<profile_type>` is one of:
|
|||
* `Localhost` to use a profile loaded on the host (see below)
|
||||
* `Unconfined` to run without AppArmor
|
||||
|
||||
See the [API Reference](#api-reference) for the full details on the AppArmor profile API.
|
||||
See [Specifying AppArmor Confinement](#specifying-apparmor-confinement) for full details on the AppArmor profile API.
|
||||
|
||||
To verify that the profile was applied, you can check that the container's root process is
|
||||
running with the correct profile by examining its proc attr:
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ En el ejemplo de abajo, el tráfico se dirige al único Endpoint definido en el
|
|||
|
||||
{{< note >}}
|
||||
El servidor de API de Kubernetes no permite hacer proxy a Endpoints que no están mapeados a Pods.
|
||||
Acciones como `kubectl proxy <service-name>` donde el servicio no tiene un selector fallará debido a esta restricción.
|
||||
Acciones como `kubectl port-forward service/<service-name> forwardedPort:servicePort` donde el servicio no tiene un selector fallará debido a esta restricción.
|
||||
Esto previene que el servidor API de Kubernetes sea utilizado como proxy a endpoints a los que quien llama no tenga acceso autorizado.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@ apiVersion: networking.k8s.io/v1
|
|||
kind: Ingress
|
||||
metadata:
|
||||
name: example-ingress
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
ingressClassName: nginx
|
||||
rules:
|
||||
|
|
|
|||
|
|
@ -3,11 +3,20 @@ layout: blog
|
|||
title: "Don't Panic: Kubernetes and Docker"
|
||||
date: 2020-12-02
|
||||
slug: dont-panic-kubernetes-and-docker
|
||||
author: >
|
||||
Jorge Castro,
|
||||
Duffie Cooley,
|
||||
Kat Cosgrove,
|
||||
Justin Garrison,
|
||||
Noah Kantrowitz,
|
||||
Bob Killen,
|
||||
Rey Lejano,
|
||||
Dan "POP" Papandrea,
|
||||
Jeffrey Sica,
|
||||
Davanum "Dims" Srinivas
|
||||
---
|
||||
|
||||
**著者:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
|
||||
|
||||
Kubernetesはv1.20より新しいバージョンで、コンテナランタイムとして[Dockerをサポートしません](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)。
|
||||
Kubernetesはv1.20より新しいバージョンで、コンテナランタイムとして[Dockerをサポートしません](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)。
|
||||
|
||||
**パニックを起こす必要はありません。これはそれほど抜本的なものではないのです。**
|
||||
|
||||
|
|
@ -20,7 +29,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ
|
|||
|
||||
もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。(Loggingなど)
|
||||
|
||||
## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。
|
||||
## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。
|
||||
ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスターの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります(他にはcontainerdやCRI-Oが挙げられます)が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。
|
||||
|
||||
お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。
|
||||
|
|
@ -32,7 +41,7 @@ DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/co
|
|||
|
||||
1つ注意すべきことは、クラスターで行われる処理のなかでDocker socket(`/var/run/docker.sock`)に依存する部分がある場合、他のRuntimeへ切り替えるとこの部分が働かなくなるでしょう。このパターンはしばしばDocker in Dockerと呼ばれます。このような場合の対応方法はたくさんあります。[kaniko](https://github.com/GoogleContainerTools/kaniko)、[img](https://github.com/genuinetools/img)、[buildah](https://github.com/containers/buildah)などです。
|
||||
|
||||
## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。
|
||||
## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。
|
||||
|
||||
この変更は、Dockerを直接操作している多くのみなさんとは別の場面に影響を与えるでしょう。
|
||||
みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスターの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ layout: blog
|
|||
title: "Kubernetesにおけるフォレンジックコンテナチェックポイント処理"
|
||||
date: 2022-12-05
|
||||
slug: forensic-container-checkpointing-alpha
|
||||
author: >
|
||||
Adrian Reber (Red Hat)
|
||||
---
|
||||
|
||||
**Authors:** Adrian Reber (Red Hat)
|
||||
|
||||
フォレンジックコンテナチェックポイント処理は[Checkpoint/Restore In Userspace](https://criu.org/) (CRIU)に基づいており、コンテナがチェックポイントされていることを認識することなく、実行中のコンテナのステートフルコピーを作成することができます。
|
||||
コンテナのコピーは、元のコンテナに気づかれることなく、サンドボックス環境で複数回の分析やリストアが可能です。
|
||||
フォレンジックコンテナチェックポイント処理はKubernetes v1.25でalpha機能として導入されました。
|
||||
|
|
|
|||
|
|
@ -3,11 +3,12 @@ layout: blog
|
|||
title: "Kubernetes 1.26: PodDisruptionBudgetによって保護された不健全なPodに対する退避ポリシー"
|
||||
date: 2023-01-06
|
||||
slug: "unhealthy-pod-eviction-policy-for-pdbs"
|
||||
author: >
|
||||
Filip Křepinský (Red Hat),
|
||||
Morten Torkildsen (Google),
|
||||
Ravi Gudimetla (Apple)
|
||||
---
|
||||
|
||||
**著者:** Filip Křepinský (Red Hat), Morten Torkildsen (Google), Ravi Gudimetla (Apple)
|
||||
|
||||
|
||||
アプリケーションの中断がその可用性に影響を与えないようにすることは、簡単な作業ではありません。
|
||||
先月リリースされたKubernetes v1.26では、[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets) (PDB) に
|
||||
_不健全なPodの退避ポリシー_ を指定して、ノード管理操作中に可用性を維持できるようになりました。
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ layout: blog
|
|||
title: "フォレンジックコンテナ分析"
|
||||
date: 2023-03-10
|
||||
slug: forensic-container-analysis
|
||||
author: >
|
||||
Adrian Reber (Red Hat)
|
||||
---
|
||||
|
||||
**Authors:** Adrian Reber (Red Hat)
|
||||
|
||||
前回投稿した[Kubernetesにおけるフォレンジックコンテナチェックポイント処理][forensic-blog]では、Kubernetesでのチェックポイントの作成や、それがどのようにセットアップされ、どのように使用されるのかを紹介しました。
|
||||
機能の名前はフォレンジックコンテナチェックポイントですが、Kubernetesによって作成されたチェックポイントの実際の分析方法については、詳細を説明しませんでした。
|
||||
この記事では、チェックポイントがどのように分析されるのかについての詳細を提供します。
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ layout: blog
|
|||
title: "SIG Releaseスポットライト(リリース・チーム・サブプロジェクト)"
|
||||
date: 2024-01-15
|
||||
slug: sig-release-spotlight-2023
|
||||
author: >
|
||||
Nitish Kumar
|
||||
---
|
||||
|
||||
**筆者:** Nitish Kumar
|
||||
|
||||
リリース・スペシャル・インタレスト・グループ(SIG Release)は、Kubernetesが4ヶ月ごとに最先端の機能とバグ修正でその刃を研ぐ場所です。Kubernetesのような大きなプロジェクトが、新バージョンをリリースするまでのタイムラインをどのように効率的に管理しているのか、またリリースチームの内部はどのようになっているのか、考えたことはありますか？このような疑問に興味がある方、もっと知りたい方、SIG Releaseの仕事に関わりたい方は、ぜひ読んでみてください！
|
||||
|
||||
SIG ReleaseはKubernetesの開発と進化において重要な役割を担っています。その主な責任は、Kubernetesの新バージョンのリリースプロセスを管理することです。[通常3〜4ヶ月ごと](https://www.kubernetes.dev/resources/release/)の定期的なリリースサイクルで運営されています。このサイクルの間、Kubernetesリリースチームは他のSIGやコントリビューターと密接に連携し、円滑でうまく調整されたリリースを保証します。これには、リリーススケジュールの計画、コードフリーズとテストフェーズの期限の設定、バイナリ、ドキュメント、リリースノートなどのリリース成果物の作成が含まれます。
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ layout: blog
|
|||
title: 'Kubernetesでコンテナを別ファイルシステムに格納する設定方法'
|
||||
date: 2024-01-23
|
||||
slug: kubernetes-separate-image-filesystem
|
||||
author: >
|
||||
Kevin Hannon (Red Hat)
|
||||
---
|
||||
|
||||
**著者:** Kevin Hannon (Red Hat)
|
||||
|
||||
**翻訳者:** Taisuke Okamoto (IDC Frontier Inc), Junya Okabe (University of Tsukuba), nasa9084 (LY Corporation)
|
||||
|
||||
Kubernetesクラスターの稼働、運用する上でよくある問題は、ディスク容量が不足することです。
|
||||
|
|
|
|||
|
|
@ -1,8 +1,10 @@
|
|||
------
|
||||
---
|
||||
layout: blog
|
||||
title: "Kubernetesブッククラブを覗く"
|
||||
slug: k8s-book-club
|
||||
date: 2024-02-22
|
||||
author: >
|
||||
Frederico Muñoz (SAS Institute)
|
||||
---
|
||||
|
||||
**著者**: Frederico Muñoz (SAS Institute)
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ layout: blog
|
|||
title: "CRI-O: OCIレジストリからのseccompプロファイルの適用"
|
||||
date: 2024-03-07
|
||||
slug: cri-o-seccomp-oci-artifacts
|
||||
author: >
|
||||
Sascha Grunert
|
||||
---
|
||||
|
||||
**著者:** Sascha Grunert
|
||||
|
||||
**翻訳者:** Taisuke Okamoto (IDC Frontier Inc), atoato88 (NEC Corporation), Junya Okabe (University of Tsukuba)
|
||||
|
||||
seccompはセキュアなコンピューティングモードを意味し、Linuxカーネルのバージョン2.6.12以降の機能として提供されました。
|
||||
|
|
|
|||
|
|
@ -2,10 +2,14 @@
|
|||
layout: blog
|
||||
title: 'Kubernetes v1.30をそっと覗く'
|
||||
date: 2024-03-12
|
||||
author: >
|
||||
Amit Dsouza,
|
||||
Frederick Kautz,
|
||||
Kristin Martin,
|
||||
Abigail McCarthy,
|
||||
Natali Vlatko
|
||||
---
|
||||
|
||||
**著者:** Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko
|
||||
|
||||
## Kubernetes v1.30のおもしろい変更点をざっと見る
|
||||
|
||||
新しい年であり、新しいKubernetesのリリースです。
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ layout: blog
|
|||
title: "DIY: Kubernetesで自分だけのクラウドを構築しよう(パート1)"
|
||||
slug: diy-create-your-own-cloud-with-kubernetes-part-1
|
||||
date: 2024-04-05T07:30:00+00:00
|
||||
author: >
|
||||
Andrei Kvapil (Ænix)
|
||||
---
|
||||
|
||||
**著者:** Andrei Kvapil (Ænix)
|
||||
|
||||
**翻訳者:** [Taisuke Okamoto](https://github.com/b1gb4by) (IDC Frontier Inc), [Junya Okabe](https://github.com/Okabe-Junya) (University of Tsukuba)
|
||||
|
||||
Ænixでは、Kubernetesに対する深い愛着があり、近いうちにすべての最新テクノロジーがKubernetesの驚くべきパターンを活用し始めることを夢見ています。
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ layout: blog
|
|||
title: "DIY: Kubernetesで自分だけのクラウドを構築しよう(パート2)"
|
||||
slug: diy-create-your-own-cloud-with-kubernetes-part-2
|
||||
date: 2024-04-05T07:35:00+00:00
|
||||
author: >
|
||||
Andrei Kvapil (Ænix)
|
||||
---
|
||||
|
||||
**著者:** Andrei Kvapil (Ænix)
|
||||
|
||||
**翻訳者:** [Taisuke Okamoto](https://github.com/b1gb4by) ([IDC Frontier Inc.](https://www.idcf.jp/)), [Daiki Hayakawa(bells17)](https://github.com/bells17) ([3-shake Inc.](https://3-shake.com/en/)), [atoato88](https://github.com/atoato88) ([NEC Corporation](https://jpn.nec.com/index.html)), [Kaito Ii](https://github.com/kaitoii11) ([Hewlett Packard Enterprise](https://www.hpe.com/jp/ja/home.html))
|
||||
|
||||
Kubernetesエコシステムだけを使って自分だけのクラウドを構築する方法について、一連の記事を続けています。
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ layout: blog
|
|||
title: "DIY: Kubernetesで自分だけのクラウドを構築しよう(パート3)"
|
||||
slug: diy-create-your-own-cloud-with-kubernetes-part-3
|
||||
date: 2024-04-05T07:40:00+00:00
|
||||
author: >
|
||||
Andrei Kvapil (Ænix)
|
||||
---
|
||||
|
||||
**著者:** Andrei Kvapil (Ænix)
|
||||
|
||||
**翻訳者:** [Taisuke Okamoto](https://github.com/b1gb4by) (IDC Frontier Inc), [Daiki Hayakawa(bells17)](https://github.com/bells17) ([3-shake Inc.](https://3-shake.com/en/)), [atoato88](https://github.com/atoato88) ([NEC Corporation](https://jpn.nec.com/index.html))
|
||||
|
||||
Kubernetesの中でKubernetesを実行するという最も興味深いフェーズに近づいています。
|
||||
|
|
|
|||
|
|
@ -3,10 +3,13 @@ layout: blog
|
|||
title: 'Kubernetes史上最大の移行作業を完了'
|
||||
date: 2024-05-20
|
||||
slug: completing-cloud-provider-migration
|
||||
author: >
|
||||
Andrew Sy Kim (Google),
|
||||
Michelle Au (Google),
|
||||
Walter Fender (Google),
|
||||
Michael McCune (Red Hat)
|
||||
---
|
||||
|
||||
**著者:** Andrew Sy Kim (Google), Michelle Au (Google), Walter Fender (Google), Michael McCune (Red Hat)
|
||||
|
||||
**翻訳者:** Taisuke Okamoto (IDC Frontier Inc), [Junya Okabe](https://github.com/Okabe-Junya) (University of Tsukuba)
|
||||
|
||||
Kubernetes v1.7以降、Kubernetesプロジェクトは、クラウドプロバイダーとの統合機能をKubernetesのコアコンポーネントから分離するという野心的な目標を追求してきました([KEP-2395](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cloud-provider/2395-removing-in-tree-cloud-providers/README.md))。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,120 @@
|
|||
---
|
||||
tille: ワークロードの自動スケーリング
|
||||
description: >-
|
||||
自動スケーリングによって、何らかのかたちでワークロードを自動的に更新できます。これによりクラスターはリソース要求の変化に対してより弾力的かつ効率的に対応できるようになります。
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetesでは、現在のリソース要求に応じてワークロードをスケールできます。
|
||||
これによりクラスターはリソース要求の変化に対してより弾力的かつ効率的に対応できるようになります。
|
||||
|
||||
ワークロードをスケールするとき、ワークロードによって管理されるレプリカ数を増減したり、レプリカで使用可能なリソースをインプレースで調整できます。
|
||||
|
||||
ひとつ目のアプローチは _水平スケーリング_ と呼ばれ、一方でふたつ目のアプローチは _垂直スケーリング_ と呼ばれます。
|
||||
|
||||
ユースケースに応じて、ワークロードをスケールするには手動と自動の方法があります。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## ワークロードを手動でスケーリングする {#scaling-workloads-manually}
|
||||
|
||||
Kubernetesはワークロードの _手動スケーリング_ をサポートします。
|
||||
水平スケーリングは `kubectl` CLIを使用して行うことができます。
|
||||
垂直スケーリングの場合、ワークロードのリソース定義を _パッチ適用_ する必要があります。
|
||||
|
||||
両方の戦略の例については以下をご覧ください。
|
||||
|
||||
- **水平スケーリング**: [Running multiple instances of your app](/ja/docs/tutorials/kubernetes-basics/scale/scale-intro/)
|
||||
- **垂直スケーリング**: [Resizing CPU and memory resources assigned to containers](/docs/tasks/configure-pod-container/resize-container-resources)
|
||||
|
||||
## ワークロードを自動でスケーリングする {#scaling-workloads-automatically}
|
||||
|
||||
Kubernetesはワークロードの _自動スケーリング_ もサポートしており、これがこのページの焦点です。
|
||||
|
||||
Kubernetesにおける _オートスケーリング_ の概念は一連のPodを管理するオブジェクト(例えば{{< glossary_tooltip text="Deployment" term_id="deployment" >}})を自動的に更新する機能を指します。
|
||||
|
||||
### ワークロードを水平方向にスケーリングする {#scaling-workloads-horizontally}
|
||||
|
||||
Kubernetesにおいて、 _HorizontalPodAutoscaler_ (HPA)を使用してワークロードを水平方向に自動的にスケールできます。
|
||||
|
||||
これはKubernetes APIリソースおよび{{< glossary_tooltip text="コントローラー" term_id="controller">}}として実装されておりCPUやメモリ使用率のような観測されたリソース使用率と一致するようにワークロードの{{<glossary_tooltip text="レプリカ" term_id="replica" >}}数を定期的に調整します。
|
||||
|
||||
Deployment用のHorizontalPodAutoscalerを構成する[ウォークスルーチュートリアル](/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough)があります。
|
||||
|
||||
### ワークロードを垂直方向にスケーリングする {#scaling-workloads-vertically}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.25" state="stable" >}}
|
||||
|
||||
_VerticalPodAutoscaler_ (VPA)を使用してワークロードを垂直方向に自動的にスケールできます。
|
||||
HPAと異なり、VPAはデフォルトでKubernetesに付属していませんが、[GitHubで](https://github.com/kubernetes/autoscaler/tree/9f87b78df0f1d6e142234bb32e8acbd71295585a/vertical-pod-autoscaler)見つかる別のプロジェクトです。
|
||||
|
||||
インストールすることにより、管理されたレプリカのリソースを _どのように_ _いつ_ スケールするのかを定義するワークロードの{{< glossary_tooltip text="CustomResourceDefinitions" term_id="customresourcedefinition" >}}(CRDs)を作成できるようになります。
|
||||
|
||||
{{< note >}}
|
||||
HPAが機能するにはクラスターに[Metrics Server](https://github.com/kubernetes-sigs/metrics-server)がインストールされている必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
現時点では、VPAは4つの異なるモードで動作できます:
|
||||
|
||||
{{< table caption="VPAの異なるモード" >}}
|
||||
モード | 説明
|
||||
:----|:-----------
|
||||
`Auto` | 現在、`Recreate`は将来インプレースアップデートに変更される可能性があります
|
||||
`Recreate` | VPAはPod作成時にリソースリクエストを割り当てるだけでなく、要求されたリソースが新しい推奨事項と大きく異なる場合にそれらを削除することによって既存のPod上でリソースリクエストを更新します
|
||||
`Initial` | VPAはPod作成時にリソースリクエストを割り当て、後から変更することはありません
|
||||
`Off` | VPAはPodのリソース要件を自動的に変更しません。推奨事項は計算され、VPAオブジェクトで検査できます
|
||||
{{< /table >}}
|
||||
|
||||
#### インプレースリサイズの要件 {#requirements-for-in-place-resizing}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.27" state="alpha" >}}
|
||||
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}}またはその{{< glossary_tooltip text="コンテナ" term_id="container" >}}を再起動**せずに**インプレースでワークロードをリサイズするには、Kubernetesバージョン1.27以降が必要です。
|
||||
さらに、`InPlaceVerticalScaling`フィーチャーゲートを有効にする必要があります。
|
||||
|
||||
{{< feature-gate-description name="InPlacePodVerticalScaling" >}}
|
||||
|
||||
### クラスターサイズに基づく自動スケーリング {#autoscaling-based-on-cluster-size}
|
||||
|
||||
クラスターのサイズに基づいてスケールする必要があるワークロード（例えば`cluster-dns`や他のシステムコンポーネント）の場合は、[_Cluster Proportional Autoscaler_](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)を使用できます。
|
||||
VPAと同じように、これはKubernetesのコア部分ではありませんが、独自のGitHubプロジェクトとしてホストされています。
|
||||
|
||||
Cluster Proportional Autoscalerはスケジュール可能な{{< glossary_tooltip text="ノード" term_id="node" >}}とコアの数を監視し、それに応じてターゲットワークロードのレプリカ数をスケールします。
|
||||
|
||||
レプリカ数を同じままにする必要がある場合、[_Cluster Proportional Vertical Autoscaler_](https://github.com/kubernetes-sigs/cluster-proportional-vertical-autoscaler)を使用してクラスターサイズに応じてワークロードを垂直方向にスケールできます。
|
||||
このプロジェクトは**現在ベータ版**でありGitHubで見つけることができます。
|
||||
|
||||
Cluster Proportional Autoscalerがワークロードのレプリカ数をスケールする一方で、Cluster Proportional Vertical Autoscalerはクラスター内のノードおよび/またはコアの数に基づいてワークロード（例えばDeploymentやDaemonSet）のリソース要求を調整します。
|
||||
|
||||
### イベント駆動型自動スケーリング {#event-driven-autoscaling}
|
||||
|
||||
例えば[_Kubernetes Event Driven Autoscaler_
|
||||
(**KEDA**)](https://keda.sh/)を使用して、イベントに基づいてワークロードをスケールすることもできます。
|
||||
|
||||
KEDAは例えばキューのメッセージ数などの処理するべきイベント数に基づいてワークロードをスケールするCNCF graduatedプロジェクトです。様々なイベントソースに合わせて選択できる幅広いアダプターが存在します。
|
||||
|
||||
### スケジュールに基づく自動スケーリング {#autoscaling-based-on-schedules}
|
||||
|
||||
ワークロードををスケールするためのもう一つの戦略は、例えばオフピークの時間帯にリソース消費を削減するために、スケーリング操作を**スケジュールする**ことです。
|
||||
|
||||
イベント駆動型オートスケーリングと同様に、そのような動作はKEDAを[`Cron`スケーラー](https://keda.sh/docs/2.13/scalers/cron/)と組み合わせて使用することで実現できます。
|
||||
`Cron`スケーラーによりワークロードをスケールインまたはスケールアウトするためのスケジュール（およびタイムゾーン）を定義できます。
|
||||
|
||||
## クラスターのインフラストラクチャーのスケーリング {#scaling-cluster-infrastructure}
|
||||
|
||||
ワークロードのスケーリングだけではニーズを満たすのに十分でない場合は、クラスターのインフラストラクチャー自体をスケールすることもできます。
|
||||
|
||||
クラスターのインフラストラクチャーのスケーリングは通常{{< glossary_tooltip text="ノード" term_id="node" >}}の追加または削除を意味します。
|
||||
詳しくは[クラスターの自動スケーリング](/docs/concepts/cluster-administration/cluster-autoscaling/)を読んでください。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- 水平スケーリングについて詳しく学ぶ
|
||||
- [StatefulSetのスケール](/ja/docs/tasks/run-application/scale-stateful-set/)
|
||||
- [HorizontalPodAutoscalerウォークスルー](/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
|
||||
- [コンテナリソースのインプレースサイズ変更](/docs/tasks/configure-pod-container/resize-container-resources/)
|
||||
- [クラスター内のDNSサービスを自動スケールする](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
|
||||
- [クラスターの自動スケーリング](/docs/concepts/cluster-administration/cluster-autoscaling/)について学ぶ
|
||||
|
|
@ -0,0 +1,210 @@
|
|||
---
|
||||
title: ロールと責任
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
誰もがKubernetesに貢献することができます。
|
||||
SIG Docs へのコントリビューションが増えると、コミュニティ内で異なるレベルのメンバーシップに申請することができます。
|
||||
これらの役割により、コミュニティ内でより多くの責任を担うことができます。
|
||||
各役割にはより多くの時間とコミットメントが必要です。
|
||||
役割は以下の通りです:
|
||||
|
||||
- Anyone: Kubernetesドキュメントへの定期的なコントリビューター
|
||||
- Member: Issueの割り当てとトリアージができ、Pull Requestに対する非公式なレビューができる
|
||||
- Reviewer: ドキュメントのPull Requestのレビューをリードし、変更の品質を保証する
|
||||
- Approver: ドキュメントのレビューをリードし、変更をマージできる
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Anyone {#anyone}
|
||||
|
||||
GitHubのアカウントを持っている人なら誰もがKubernetesに貢献することができます。
|
||||
SIG Docs はすべての新たなコントリビューターを歓迎します。
|
||||
|
||||
誰もが以下のことをできます:
|
||||
|
||||
- [`kubernetes/website`](https://github.com/kubernetes/website)を含む、どの[Kubernetes](https://github.com/kubernetes/)リポジトリでもIssueを作成する
|
||||
- Pull Requestに非公式なフィードバックを提供する
|
||||
- ローカライゼーションに貢献する
|
||||
- [Slack](https://slack.k8s.io/)や[SIG Docsのメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)で改善の提案をする
|
||||
|
||||
[CLA に署名](https://github.com/kubernetes/community/blob/master/CLA.md)した後は、誰もが以下のことをできます:
|
||||
|
||||
- 既存のコンテンツを改善するためのPull Requestを開く、新しいコンテンツを追加する、ブログ記事やケーススタディを書く
|
||||
- 図表やグラフィックアセット、埋め込み可能なスクリーンキャストやビデオを作成する
|
||||
|
||||
詳細については、[新しいコンテンツの貢献](/ja/docs/contribute/new-content/)を参照してください。
|
||||
|
||||
## Member {#members}
|
||||
|
||||
Memberは、`kubernetes/website`に複数のPull Requestを作成した人です。
|
||||
Memberは[Kubernetes GitHub organization](https://github.com/kubernetes)の一員です。
|
||||
|
||||
Memberは以下のことをできます:
|
||||
|
||||
- [Anyone](#anyone)に列挙されているすべてのことを行う
|
||||
- `/lgtm`コメントを使用して、Pull RequestにLGTM (looks good to me)ラベルを追加する
|
||||
|
||||
{{< note >}}
|
||||
`/lgtm`を使用すると、自動化がトリガーされます。
|
||||
非公式に承認したい場合は、"LGTM"とコメントするだけでも大丈夫です！
|
||||
{{< /note >}}
|
||||
|
||||
- `/hold`コメントを使用して、Pull Requestのマージをブロックする
|
||||
- `/assign`コメントを使用して、Pull RequestにReviewerを割り当てる
|
||||
- Pull Requestに非公式なレビューを提供する
|
||||
- 自動化を使用してIssueをトリアージし、分類する
|
||||
- 新機能をドキュメント化する
|
||||
|
||||
### Memberになる {#becoming-a-member}
|
||||
|
||||
少なくとも5つの実質的なPull Requestを作成し、その他の[要件](https://github.com/kubernetes/community/blob/master/community-membership.md#member)を満たした後に以下のようにしてMemberになることができます:
|
||||
|
||||
1. 2人の[Reviewer](#reviewers)または[Approver](#approvers)にあなたのメンバーシップを[スポンサー](/docs/contribute/advanced#sponsor-a-new-contributor)してもらいます。
|
||||
|
||||
[Slackの#sig-docsチャンネル](https://kubernetes.slack.com)や[SIG Docsのメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)でスポンサーを依頼してください。
|
||||
|
||||
{{< note >}}
|
||||
個別のSIG Docsメンバーに直接メールやSlackのダイレクトメッセージを送らないでください。
|
||||
また申請する前にスポンサーを依頼する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
2. [`kubernetes/org`](https://github.com/kubernetes/org/)リポジトリにIssueを作成します。**Organization Membership Request**のissueテンプレートを使用してください。
|
||||
|
||||
3. スポンサーにGitHub Issueのことを知らせます。以下の方法があります:
|
||||
- Issue内でGitHubユーザー名に言及する（`@<GitHub-username>`）
|
||||
- Slackやメールを使ってIssueのリンクを送る
|
||||
|
||||
スポンサーは`+1`の投票でリクエストを承認します。
|
||||
スポンサーがリクエストを承認すると、Kubernetes GitHubの管理者があなたをメンバーとして追加します。
|
||||
おめでとうございます！
|
||||
|
||||
メンバーシップリクエストが承認されない場合はフィードバックを受け取ります。
|
||||
フィードバックに対応した後、再度申請してください。
|
||||
|
||||
4. メールアカウントでKubernetes GitHub organizationの招待を受け入れます。
|
||||
|
||||
{{< note >}}
|
||||
GitHubはアカウントのデフォルトメールアドレスに招待を送信します。
|
||||
{{< /note >}}
|
||||
|
||||
## Reviewer {#reviewers}
|
||||
|
||||
ReviewerはオープンなPull Requestのレビューを担当します。
|
||||
Memberのフィードバックとは異なり、PRを作成した人はReviewerのフィードバックに対応する必要があります。
|
||||
Reviewerは[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHubチームのメンバーです。
|
||||
|
||||
Reviewerは以下のことをできます:
|
||||
|
||||
- [Anyone](#anyone)および[Member](#members)に列挙されているすべてのことを行う
|
||||
- Pull Requestをレビューし、拘束力のあるフィードバックを提供する
|
||||
|
||||
{{< note >}}
|
||||
拘束力のないフィードバックを提供する場合、コメントの前に"Optionally: "などのフレーズを付けてください。
|
||||
{{< /note >}}
|
||||
|
||||
- コード内のユーザー向けの文字列を編集する
|
||||
- コードコメントを改善する
|
||||
|
||||
SIG DocsのReviewer、あるいは特定の領域に関するドキュメントのReviewerになることができます。
|
||||
|
||||
### Pull RequestへのReviewerの割り当て
|
||||
|
||||
自動化により、すべてのPull RequestにReviewerが割り当てられます。
|
||||
特定の人物にレビューを依頼するには、`/assign [@_github_handle]`とコメントします。
|
||||
|
||||
割り当てられたReviewerがPRにコメントしていない場合、他のReviewerが代わりにレビューできます。
|
||||
また、必要に応じて技術的なReviewerを割り当てることもできます。
|
||||
|
||||
### `/lgtm`の使用
|
||||
|
||||
LGTMは"Looks good to me"の略で、Pull Requestが技術的に正確でマージの準備が整っていることを示します。
|
||||
すべてのPRには、マージするためにReviewerからの`/lgtm`コメントとApproverからの`/approve`コメントが必要です。
|
||||
|
||||
Reviewerからの`/lgtm`コメントは拘束力があり、自動化により`lgtm`ラベルが追加されます。
|
||||
|
||||
### Reviewerになる
|
||||
|
||||
[要件](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)を満たすと、SIG DocsのReviewerになることができます。他のSIGのReviewerは、SIG DocsでのReviewerステータスを別途申請する必要があります。
|
||||
|
||||
申請方法は以下の通りです:
|
||||
|
||||
1. `kubernetes/website`リポジトリの[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)ファイルのセクションに、GitHubユーザー名を追加するPull Requestを開きます。
|
||||
|
||||
{{< note >}}
|
||||
どこに追加すればよいかわからない場合は、`sig-docs-en-reviews`に追加してください。
|
||||
|
||||
訳注: `sig-docs-en-reviews`は英語版のReviewerチームです。日本語ローカライゼーションのReviewerチームに参加する場合は、`sig-docs-ja-reviews`に追加してください。
|
||||
{{< /note >}}
|
||||
|
||||
2. PRを1人以上のSIG Docs Approverに割り当てます(ユーザー名は`sig-docs-{language}-owners`に記載されています)。
|
||||
|
||||
承認されると、SIG Docsのリードが適切なGitHubチームに追加します。
|
||||
追加されると、[k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)が新しいPull RequestのReviewerとしてあなたを割り当て、提案します。
|
||||
|
||||
## Approver {#approvers}
|
||||
|
||||
ApproverはPull Requestをレビューし、マージするために承認します。
|
||||
Approverは[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHubチームのメンバーです。
|
||||
|
||||
Approverは以下のことをできます:
|
||||
|
||||
- [Anyone](#anyone)、[Member](#members)、および[Reviewer](#reviewers)に列挙されているすべてのことを行う
|
||||
- `/approve`コメントを使用してPull Requestを承認およびマージすることで、コントリビューターのコンテンツを公開する
|
||||
- スタイルガイドの改善を提案する
|
||||
- ドキュメントテストの改善を提案する
|
||||
- Kubernetesのウェブサイトや他のツールの改善を提案する
|
||||
|
||||
PRに既に`/lgtm`が付いている場合、またはApprover自身が`/lgtm`コメントを付けた場合、PRは自動的にマージされます。
|
||||
SIG DocsのApproverは、追加の技術的なレビューが不要な変更にのみ`/lgtm`を付けるべきです。
|
||||
|
||||
### Pull Requestの承認
|
||||
|
||||
ApproverとSIG DocsのリードだけがPull Requestをwebsiteリポジトリにマージすることができます。
|
||||
これには一定の責任が伴います。
|
||||
|
||||
- Approverは`/approve`コマンドを使用して、PRをリポジトリにマージできます。
|
||||
|
||||
{{< warning >}}
|
||||
不注意なマージはサイトを壊す可能性があるため、マージする際には慎重に行ってください。
|
||||
{{< /warning >}}
|
||||
|
||||
- 提案された変更が[ドキュメントコンテンツガイド](/docs/contribute/style/content-guide/)に準拠していることを確認してください。
|
||||
|
||||
もし疑問がある場合や何か不明な点がある場合は、遠慮なく追加のレビューを依頼してください。
|
||||
|
||||
- PRを`/approve`する前に、Netlifyのテストに通っていることを確認してください。
|
||||
|
||||
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlifyテストは承認する前に通っている必要があります" />
|
||||
|
||||
- 承認する前に、PRのNetlifyのページプレビューをクリックして内容が正しいことを確認してください。
|
||||
|
||||
- 週ごとのローテーションである[PR Wranglerローテーションスケジュール](https://github.com/kubernetes/website/wiki/PR-Wranglers)に参加してください。SIG DocsはすべてのApproverにこのローテーションへの参加を期待しています。詳細については[PR wranglers](/docs/contribute/participate/pr-wranglers/)を参照してください。
|
||||
|
||||
### Approverになる
|
||||
|
||||
[要件](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)を満たすと、SIG DocsのApproverになることができます。
|
||||
他のSIGのApproverは、SIG DocsでのApproverステータスを別途申請する必要があります。
|
||||
|
||||
申請方法は以下の通りです:
|
||||
|
||||
1. `kubernetes/website`リポジトリの[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)ファイルのセクションに、自分自身を追加するPull Requestを開きます。
|
||||
|
||||
{{< note >}}
|
||||
どこに追加すればよいかわからない場合は、`sig-docs-en-owners`に追加してください。
|
||||
|
||||
訳注: `sig-docs-en-owners`は英語版のApproverチームです。
|
||||
日本語ローカライゼーションのApproverチームに参加する場合は、`sig-docs-ja-owners`に追加してください。
|
||||
{{< /note >}}
|
||||
|
||||
2. PRを1人以上の現在のSIG Docs Approversに割り当てます。
|
||||
|
||||
承認されると、SIG Docsのリードが適切なGitHubチームに追加します。
|
||||
追加されると、[k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)が新しいPull RequestのReviewerとしてあなたを割り当て、提案します。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- すべてのApproverがローテーションで担当する役割である[PR wrangling](/docs/contribute/participate/pr-wranglers/)について読む。
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: フィーチャーゲート(Feature gate)
|
||||
id: feature-gate
|
||||
date: 2023-01-12
|
||||
full_link: /ja/docs/reference/command-line-tools-reference/feature-gates/
|
||||
short_description: >
|
||||
特定のKubernetes機能を有効にするかどうかを制御する方法。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
フィーチャーゲートはクラスター内でどのKubernetes機能を有効にするかを制御するために使用できるキー(不透明な文字列値)のセットです。
|
||||
|
||||
<!--more-->
|
||||
各Kubernetesコンポーネントで`--feature-gates`コマンドラインフラグを使用して、これらの機能をオンまたはオフにすることができます。
|
||||
各Kubernetesコンポーネントでは、そのコンポーネントに関連する一連のフィーチャーゲートを有効または無効にすることができます。
|
||||
Kubernetesのドキュメントには、現在のすべての[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)とその制御対象がリストされています。
|
||||
|
|
@ -17,7 +17,7 @@ card:
|
|||
|
||||
この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。
|
||||
|
||||
インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。クイックガイドは、[チートシート](/ja/docs/reference/kubectl/cheatsheet/)をご覧ください。`docker`コマンドラインツールに慣れている方は、[`kubectl` for Docker Users](/docs/reference/kubectl/docker-cli-to-kubectl/)でKubernetesの同等のコマンドを説明しています。
|
||||
インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/#kubectl)をご覧ください。クイックガイドは、[チートシート](/ja/docs/reference/kubectl/cheatsheet/)をご覧ください。`docker`コマンドラインツールに慣れている方は、[`kubectl` for Docker Users](/docs/reference/kubectl/docker-cli-to-kubectl/)でKubernetesの同等のコマンドを説明しています。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@ apiVersion: networking.k8s.io/v1
|
|||
kind: Ingress
|
||||
metadata:
|
||||
name: example-ingress
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
ingressClassName: nginx
|
||||
rules:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,293 @@
|
|||
---
|
||||
layout: blog
|
||||
title: 'Kubernetes v1.31 中的移除和主要变更'
|
||||
date: 2024-07-19
|
||||
slug: kubernetes-1-31-upcoming-changes
|
||||
author: >
|
||||
Abigail McCarthy,
|
||||
Edith Puclla,
|
||||
Matteo Bianchi,
|
||||
Rashan Smith,
|
||||
Yigit Demirbas
|
||||
translator: >
|
||||
Xin Li (DaoCloud)
|
||||
---
|
||||
|
||||
<!--
|
||||
layout: blog
|
||||
title: 'Kubernetes Removals and Major Changes In v1.31'
|
||||
date: 2024-07-19
|
||||
slug: kubernetes-1-31-upcoming-changes
|
||||
author: >
|
||||
Abigail McCarthy,
|
||||
Edith Puclla,
|
||||
Matteo Bianchi,
|
||||
Rashan Smith,
|
||||
Yigit Demirbas
|
||||
-->
|
||||
|
||||
<!--
|
||||
As Kubernetes develops and matures, features may be deprecated, removed, or replaced with better ones for the project's overall health.
|
||||
This article outlines some planned changes for the Kubernetes v1.31 release that the release team feels you should be aware of for the continued maintenance of your Kubernetes environment.
|
||||
The information listed below is based on the current status of the v1.31 release.
|
||||
It may change before the actual release date.
|
||||
-->
|
||||
随着 Kubernetes 的发展和成熟，为了项目的整体健康，某些特性可能会被弃用、删除或替换为更好的特性。
|
||||
本文阐述了 Kubernetes v1.31 版本的一些更改计划，发行团队认为你应当了解这些更改，
|
||||
以便持续维护 Kubernetes 环境。
|
||||
下面列出的信息基于 v1.31 版本的当前状态；这些状态可能会在实际发布日期之前发生变化。
|
||||
|
||||
<!--
|
||||
## The Kubernetes API removal and deprecation process
|
||||
The Kubernetes project has a well-documented [deprecation policy](/docs/reference/using-api/deprecation-policy/) for features.
|
||||
This policy states that stable APIs may only be deprecated when a newer, stable version of that API is available and that APIs have a minimum lifetime for each stability level.
|
||||
A deprecated API has been marked for removal in a future Kubernetes release.
|
||||
It will continue to function until removal (at least one year from the deprecation), but usage will display a warning.
|
||||
Removed APIs are no longer available in the current version, so you must migrate to using the replacement.
|
||||
-->
|
||||
## Kubernetes API 删除和弃用流程
|
||||
|
||||
Kubernetes 项目针对其功能特性有一个详细说明的[弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。
|
||||
此策略规定，只有当某稳定 API 的更新、稳定版本可用时，才可以弃用该 API，并且 API
|
||||
的各个稳定性级别都有对应的生命周期下限。
|
||||
已弃用的 API 标记为在未来的 Kubernetes 版本中删除，
|
||||
这类 API 将继续发挥作用，直至被删除（从弃用起至少一年），但使用时会显示警告。
|
||||
已删除的 API 在当前版本中不再可用，因此你必须将其迁移到替换版本。
|
||||
|
||||
<!--
|
||||
* Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes.
|
||||
|
||||
* Beta or pre-release API versions must be supported for 3 releases after the deprecation.
|
||||
|
||||
* Alpha or experimental API versions may be removed in any release without prior deprecation notice.
|
||||
-->
|
||||
* 正式发布的（GA）或稳定的 API 版本可被标记为已弃用，但不得在 Kubernetes 主要版本未变时删除。
|
||||
|
||||
* Beta 或预发布 API 版本在被弃用后，必须保持 3 个发布版本中仍然可用。
|
||||
|
||||
* Alpha 或实验性 API 版本可以在任何版本中删除，不必提前通知。
|
||||
|
||||
<!--
|
||||
Whether an API is removed because a feature graduated from beta to stable or because that API did not succeed, all removals comply with this deprecation policy.
|
||||
Whenever an API is removed, migration options are communicated in the [documentation](/docs/reference/using-api/deprecation-guide/).
|
||||
-->
|
||||
无论 API 是因为某个特性从 Beta 版升级到稳定版，还是因为此 API 未成功而被删除，所有删除都将符合此弃用策略。
|
||||
每当删除 API 时，迁移选项都会在[文档](/zh-cn/docs/reference/using-api/deprecation-guide/)中传达。
|
||||
|
||||
<!--
|
||||
## A note about SHA-1 signature support
|
||||
|
||||
In [go1.18](https://go.dev/doc/go1.18#sha1) (released in March 2022), the crypto/x509 library started to reject certificates signed with a SHA-1 hash function.
|
||||
While SHA-1 is established to be unsafe and publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015, there might still be cases in the context of Kubernetes where user-provided certificates are signed using a SHA-1 hash function through private authorities with them being used for Aggregated API Servers or webhooks.
|
||||
If you have relied on SHA-1 based certificates, you must explicitly opt back into its support by setting `GODEBUG=x509sha1=1` in your environment.
|
||||
-->
|
||||
## 关于 SHA-1 签名支持的说明
|
||||
|
||||
在 [go1.18](https://go.dev/doc/go1.18#sha1)（2022 年 3 月发布）中，crypto/x509
|
||||
库开始拒绝使用 SHA-1 哈希函数签名的证书。
|
||||
虽然 SHA-1 被确定为不安全，并且公众信任的证书颁发机构自 2015 年以来就没有颁发过 SHA-1 证书，
|
||||
但在 Kubernetes 环境中，仍可能存在用户提供的证书通过私人颁发机构使用 SHA-1 哈希函数签名的情况，
|
||||
这些证书用于聚合 API 服务器或 Webhook。
|
||||
如果你依赖基于 SHA-1 的证书，则必须通过在环境中设置 `GODEBUG=x509sha1=1` 以明确选择重新支持这种证书。
|
||||
|
||||
<!--
|
||||
Given Go's [compatibility policy for GODEBUGs](https://go.dev/blog/compat), the `x509sha1` GODEBUG and the support for SHA-1 certificates will [fully go away in go1.24](https://tip.golang.org/doc/go1.23) which will be released in the first half of 2025.
|
||||
If you rely on SHA-1 certificates, please start moving off them.
|
||||
|
||||
Please see [Kubernetes issue #125689](https://github.com/kubernetes/kubernetes/issues/125689) to get a better idea of timelines around the support for SHA-1 going away, when Kubernetes releases plans to adopt go1.24, and for more details on how to detect usage of SHA-1 certificates via metrics and audit logging.
|
||||
-->
|
||||
鉴于 Go 的 [GODEBUG 兼容性策略](https://go.dev/blog/compat)，`x509sha1` GODEBUG
|
||||
和对 SHA-1 证书的支持将 [在 2025 年上半年发布的 go1.24](https://tip.golang.org/doc/go1.23)
|
||||
中完全消失。
|
||||
如果你依赖 SHA-1 证书，请开始放弃使用它们。
|
||||
|
||||
请参阅 [Kubernetes 问题 #125689](https://github.com/kubernetes/kubernetes/issues/125689)，
|
||||
以更好地了解对 SHA-1 支持的时间表，以及 Kubernetes 发布采用 go1.24
|
||||
的计划时间、如何通过指标和审计日志检测 SHA-1 证书使用情况的更多详细信息。
|
||||
|
||||
<!--
|
||||
## Deprecations and removals in Kubernetes 1.31
|
||||
|
||||
### Deprecation of `status.nodeInfo.kubeProxyVersion` field for Nodes ([KEP 4004](https://github.com/kubernetes/enhancements/issues/4004))
|
||||
-->
|
||||
## Kubernetes 1.31 中的弃用和删除
|
||||
|
||||
### 弃用节点的 `status.nodeInfo.kubeProxyVersion` 字段（[KEP 4004](https://github.com/kubernetes/enhancements/issues/4004)）
|
||||
|
||||
<!--
|
||||
The `.status.nodeInfo.kubeProxyVersion` field of Nodes is being deprecated in Kubernetes v1.31,and will be removed in a later release.
|
||||
It's being deprecated because the value of this field wasn't (and isn't) accurate.
|
||||
This field is set by the kubelet, which does not have reliable information about the kube-proxy version or whether kube-proxy is running.
|
||||
|
||||
The `DisableNodeKubeProxyVersion` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) will be set to `true` in by default in v1.31 and the kubelet will no longer attempt to set the `.status.kubeProxyVersion` field for its associated Node.
|
||||
-->
|
||||
Node 的 `.status.nodeInfo.kubeProxyVersion` 字段在 Kubernetes v1.31 中将被弃用，
|
||||
并将在后续版本中删除。该字段被弃用是因为其取值原来不准确，并且现在也不准确。
|
||||
该字段由 kubelet 设置，而 kubelet 没有关于 kube-proxy 版本或 kube-proxy 是否正在运行的可靠信息。
|
||||
|
||||
在 v1.31 中，`DisableNodeKubeProxyVersion`
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)将默认设置为 `true`，
|
||||
并且 kubelet 将不再尝试为其关联的 Node 设置 `.status.kubeProxyVersion` 字段。
|
||||
|
||||
<!--
|
||||
### Removal of all in-tree integrations with cloud providers
|
||||
|
||||
As highlighted in a [previous article](/blog/2024/05/20/completing-cloud-provider-migration/), the last remaining in-tree support for cloud provider integration will be removed as part of the v1.31 release.
|
||||
This doesn't mean you can't integrate with a cloud provider, however you now **must** use the
|
||||
recommended approach using an external integration. Some integrations are part of the Kubernetes
|
||||
project and others are third party software.
|
||||
-->
|
||||
### 删除所有云驱动的树内集成组件
|
||||
|
||||
正如[之前一篇文章](/blog/2024/05/20/completing-cloud-provider-migration/)中所强调的，
|
||||
v1.31 版本将删除云驱动集成的树内支持的最后剩余部分。
|
||||
这并不意味着你无法与某云驱动集成，只是你现在**必须**使用推荐的外部集成方法。
|
||||
一些集成组件是 Kubernetes 项目的一部分，其余集成组件则是第三方软件。
|
||||
|
||||
<!--
|
||||
This milestone marks the completion of the externalization process for all cloud providers' integrations from the Kubernetes core ([KEP-2395](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cloud-provider/2395-removing-in-tree-cloud-providers/README.md)), a process started with Kubernetes v1.26.
|
||||
This change helps Kubernetes to get closer to being a truly vendor-neutral platform.
|
||||
|
||||
For further details on the cloud provider integrations, read our [v1.29 Cloud Provider Integrations feature blog](/blog/2023/12/14/cloud-provider-integration-changes/).
|
||||
For additional context about the in-tree code removal, we invite you to check the ([v1.29 deprecation blog](/blog/2023/11/16/kubernetes-1-29-upcoming-changes/#removal-of-in-tree-integrations-with-cloud-providers-kep-2395-https-kep-k8s-io-2395)).
|
||||
|
||||
The latter blog also contains useful information for users who need to migrate to version v1.29 and later.
|
||||
-->
|
||||
这一里程碑标志着将所有云驱动集成组件从 Kubernetes 核心外部化的过程已经完成
|
||||
（[KEP-2395](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cloud-provider/2395-removing-in-tree-cloud-providers/README.md)），
|
||||
该过程从 Kubernetes v1.26 开始。
|
||||
这一变化有助于 Kubernetes 进一步成为真正的供应商中立平台。
|
||||
|
||||
有关云驱动集成的更多详细信息，请阅读我们的 [v1.29 云驱动集成特性的博客](/zh-cn/blog/2023/12/14/cloud-provider-integration-changes/)。
|
||||
有关树内代码删除的更多背景信息，请阅读
|
||||
（[v1.29 弃用博客](/blog/2023/11/16/kubernetes-1-29-upcoming-changes/#removal-of-in-tree-integrations-with-cloud-providers-kep-2395-https-kep-k8s-io-2395)）。
|
||||
|
||||
后一个博客还包含对需要迁移到 v1.29 及更高版本的用户有用的信息。
|
||||
|
||||
<!--
|
||||
### Removal of kubelet `--keep-terminated-pod-volumes` command line flag
|
||||
|
||||
The kubelet flag `--keep-terminated-pod-volumes`, which was deprecated in 2017, will be removed as
|
||||
part of the v1.31 release.
|
||||
|
||||
You can find more details in the pull request [#122082](https://github.com/kubernetes/kubernetes/pull/122082).
|
||||
-->
|
||||
### 删除 kubelet `--keep-terminated-pod-volumes` 命令行标志
|
||||
|
||||
kubelet 标志 `--keep-terminated-pod-volumes` 已于 2017 年弃用，将在 v1.31 版本中被删除。
|
||||
|
||||
你可以在拉取请求 [#122082](https://github.com/kubernetes/kubernetes/pull/122082)
|
||||
中找到更多详细信息。
|
||||
|
||||
<!--
|
||||
### Removal of CephFS volume plugin
|
||||
|
||||
[CephFS volume plugin](/docs/concepts/storage/volumes/#cephfs) was removed in this release and the `cephfs` volume type became non-functional.
|
||||
|
||||
It is recommended that you use the [CephFS CSI driver](https://github.com/ceph/ceph-csi/) as a third-party storage driver instead. If you were using the CephFS volume plugin before upgrading the cluster version to v1.31, you must re-deploy your application to use the new driver.
|
||||
|
||||
CephFS volume plugin was formally marked as deprecated in v1.28.
|
||||
-->
|
||||
### 删除 CephFS 卷插件
|
||||
|
||||
[CephFS 卷插件](/zh-cn/docs/concepts/storage/volumes/#cephfs)已在此版本中删除，
|
||||
并且 `cephfs` 卷类型已无法使用。
|
||||
|
||||
建议你改用 [CephFS CSI 驱动程序](https://github.com/ceph/ceph-csi/) 作为第三方存储驱动程序。
|
||||
如果你在将集群版本升级到 v1.31 之前在使用 CephFS 卷插件，则必须重新部署应用才能使用新驱动。
|
||||
|
||||
CephFS 卷插件在 v1.28 中正式标记为已弃用。
|
||||
|
||||
<!--
|
||||
### Removal of Ceph RBD volume plugin
|
||||
|
||||
The v1.31 release will remove the [Ceph RBD volume plugin](/docs/concepts/storage/volumes/#rbd) and its CSI migration support, making the `rbd` volume type non-functional.
|
||||
|
||||
It's recommended that you use the [RBD CSI driver](https://github.com/ceph/ceph-csi/) in your clusters instead.
|
||||
If you were using Ceph RBD volume plugin before upgrading the cluster version to v1.31, you must re-deploy your application to use the new driver.
|
||||
|
||||
The Ceph RBD volume plugin was formally marked as deprecated in v1.28.
|
||||
-->
|
||||
### 删除 Ceph RBD 卷插件
|
||||
|
||||
v1.31 版本将删除 [Ceph RBD 卷插件](/zh-cn/docs/concepts/storage/volumes/#rbd)及其 CSI 迁移支持，
|
||||
`rbd` 卷类型将无法继续使用。
|
||||
|
||||
建议你在集群中使用 [RBD CSI 驱动](https://github.com/ceph/ceph-csi/)。
|
||||
如果你在将集群版本升级到 v1.31 之前在使用 Ceph RBD 卷插件，则必须重新部署应用以使用新驱动。
|
||||
|
||||
Ceph RBD 卷插件在 v1.28 中正式标记为已弃用。
|
||||
|
||||
<!--
|
||||
### Deprecation of non-CSI volume limit plugins in kube-scheduler
|
||||
|
||||
The v1.31 release will deprecate all non-CSI volume limit scheduler plugins, and will remove some
|
||||
already deprected plugins from the [default plugins](/docs/reference/scheduling/config/), including:
|
||||
-->
|
||||
### kube-scheduler 中非 CSI 卷限制插件的弃用
|
||||
|
||||
v1.31 版本将弃用所有非 CSI 卷限制调度程序插件，
|
||||
并将从[默认插件](/zh-cn/docs/reference/scheduling/config/)中删除一些已弃用的插件，包括：
|
||||
|
||||
- `AzureDiskLimits`
|
||||
- `CinderLimits`
|
||||
- `EBSLimits`
|
||||
- `GCEPDLimits`
|
||||
|
||||
<!--
|
||||
It's recommended that you use the `NodeVolumeLimits` plugin instead because it can handle the same functionality as the removed plugins since those volume types have been migrated to CSI.
|
||||
Please replace the deprecated plugins with the `NodeVolumeLimits` plugin if you explicitly use them in the [scheduler config](/docs/reference/scheduling/config/).
|
||||
The `AzureDiskLimits`, `CinderLimits`, `EBSLimits`, and `GCEPDLimits` plugins will be removed in a future release.
|
||||
|
||||
These plugins will be removed from the default scheduler plugins list as they have been deprecated since Kubernetes v1.14.
|
||||
-->
|
||||
建议你改用 `NodeVolumeLimits` 插件，因为它可以处理与已删除插件相同的功能，因为这些卷类型已迁移到 CSI。
|
||||
如果你在[调度器配置](/zh-cn/docs/reference/scheduling/config/)中显式使用已弃用的插件，
|
||||
请用 `NodeVolumeLimits` 插件替换它们。
|
||||
`AzureDiskLimits`、`CinderLimits`、`EBSLimits` 和 `GCEPDLimits` 插件将在未来的版本中被删除。
|
||||
|
||||
这些插件将从默认调度程序插件列表中删除，因为它们自 Kubernetes v1.14 以来已被弃用。
|
||||
|
||||
<!--
|
||||
## Looking ahead
|
||||
The official list of API removals planned for [Kubernetes v1.32](/docs/reference/using-api/deprecation-guide/#v1-32) include:
|
||||
|
||||
* The `flowcontrol.apiserver.k8s.io/v1beta3` API version of FlowSchema and PriorityLevelConfiguration will be removed.
|
||||
To prepare for this, you can edit your existing manifests and rewrite client software to use the `flowcontrol.apiserver.k8s.io/v1 API` version, available since v1.29.
|
||||
All existing persisted objects are accessible via the new API. Notable changes in flowcontrol.apiserver.k8s.io/v1beta3 include that the PriorityLevelConfiguration `spec.limited.nominalConcurrencyShares` field only defaults to 30 when unspecified, and an explicit value of 0 is not changed to 30.
|
||||
|
||||
For more information, please refer to the [API deprecation guide](/docs/reference/using-api/deprecation-guide/#v1-32).
|
||||
-->
|
||||
## 展望未来
|
||||
|
||||
[Kubernetes v1.32](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-32) 计划删除的官方 API 包括：
|
||||
|
||||
* 将删除 `flowcontrol.apiserver.k8s.io/v1beta3` API 版本的 FlowSchema 和 PriorityLevelConfiguration。
|
||||
为了做好准备，你可以编辑现有清单并重写客户端软件以使用自 v1.29 起可用的 `flowcontrol.apiserver.k8s.io/v1 API` 版本。
|
||||
所有现有的持久化对象都可以通过新 API 访问。`flowcontrol.apiserver.k8s.io/v1beta3` 中需要注意的变化包括优先级配置
|
||||
`spec.limited.nominalConcurrencyShares` 字段仅在未指定时默认为 30，并且显式设置为 0 的话不会被更改为 30。
|
||||
|
||||
有关更多信息，请参阅 [API 弃用指南](/docs/reference/using-api/deprecation-guide/#v1-32)。
|
||||
|
||||
<!--
|
||||
## Want to know more?
|
||||
The Kubernetes release notes announce deprecations.
|
||||
We will formally announce the deprecations in [Kubernetes v1.31](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md#deprecation) as part of the CHANGELOG for that release.
|
||||
|
||||
You can see the announcements of pending deprecations in the release notes for:
|
||||
-->
|
||||
## 想要了解更多？
|
||||
|
||||
Kubernetes 发行说明中会宣布弃用信息。
|
||||
我们将在 [Kubernetes v1.31](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md#deprecation)
|
||||
中正式宣布弃用信息，作为该版本的 CHANGELOG 的一部分。
|
||||
|
||||
你可以在发行说明中看到待弃用的公告：
|
||||
|
||||
* [Kubernetes v1.30](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md#deprecation)
|
||||
|
||||
* [Kubernetes v1.29](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#deprecation)
|
||||
|
||||
* [Kubernetes v1.28](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.28.md#deprecation)
|
||||
|
||||
* [Kubernetes v1.27](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md#deprecation)
|
||||
|
|
@ -619,13 +619,11 @@ You can create an `Opaque` type for credentials used for basic authentication.
|
|||
However, using the defined and public Secret type (`kubernetes.io/basic-auth`) helps other
|
||||
people to understand the purpose of your Secret, and sets a convention for what key names
|
||||
to expect.
|
||||
The Kubernetes API verifies that the required keys are set for a Secret of this type.
|
||||
-->
|
||||
提供基本身份认证类型的 Secret 仅仅是出于方便性考虑。
|
||||
你也可以使用 `Opaque` 类型来保存用于基本身份认证的凭据。
|
||||
不过，使用预定义的、公开的 Secret 类型（`kubernetes.io/basic-auth`）
|
||||
有助于帮助其他用户理解 Secret 的目的，并且对其中存在的主键形成一种约定。
|
||||
API 服务器会检查 Secret 配置中是否提供了所需要的主键。
|
||||
|
||||
<!--
|
||||
### SSH authentication Secrets
|
||||
|
|
|
|||
|
|
@ -213,7 +213,7 @@ operator.
|
|||
|
||||
<!--
|
||||
* [Charmed Operator Framework](https://juju.is/)
|
||||
* [Java Operator SDK](https://github.com/java-operator-sdk/java-operator-sdk)
|
||||
* [Java Operator SDK](https://github.com/operator-framework/java-operator-sdk)
|
||||
* [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework)
|
||||
* [kube-rs](https://kube.rs/) (Rust)
|
||||
* [kubebuilder](https://book.kubebuilder.io/)
|
||||
|
|
@ -226,7 +226,7 @@ operator.
|
|||
-->
|
||||
|
||||
* [Charmed Operator Framework](https://juju.is/)
|
||||
* [Java Operator SDK](https://github.com/java-operator-sdk/java-operator-sdk)
|
||||
* [Java Operator SDK](https://github.com/operator-framework/java-operator-sdk)
|
||||
* [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework)
|
||||
* [kube-rs](https://kube.rs/) (Rust)
|
||||
* [kubebuilder](https://book.kubebuilder.io/)
|
||||
|
|
|
|||
|
|
@ -54,11 +54,13 @@ Kubernetes 证书和信任包（trust bundle）API 可以通过为 Kubernetes AP
|
|||
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
|
||||
|
||||
<!--
|
||||
A CertificateSigningRequest (CSR) resource is used to request that a certificate be signed
|
||||
A [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
|
||||
(CSR) resource is used to request that a certificate be signed
|
||||
by a denoted signer, after which the request may be approved or denied before
|
||||
finally being signed.
|
||||
-->
|
||||
CertificateSigningRequest（CSR）资源用来向指定的签名者申请证书签名，
|
||||
[CertificateSigningRequest](/zh-cn/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
|
||||
（CSR）资源用来向指定的签名者申请证书签名，
|
||||
在最终签名之前，申请可能被批准，也可能被拒绝。
|
||||
|
||||
<!--
|
||||
|
|
@ -344,7 +346,7 @@ Kubernetes 提供了内置的签名者，每个签名者都有一个众所周知
|
|||
May be auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
|
||||
1. Trust distribution: signed certificates must be honored as client certificates by the API server. The CA bundle
|
||||
is not distributed by any other means.
|
||||
1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name starts with "`system:node:`".
|
||||
1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name is "`system:node:${NODE_NAME}`".
|
||||
1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions and drops other extensions.
|
||||
1. Permitted key usages - `["key encipherment", "digital signature", "client auth"]` or `["digital signature", "client auth"]`.
|
||||
1. Expiration/certificate lifetime - for the kube-controller-manager implementation of this signer, set to the minimum
|
||||
|
|
@ -355,7 +357,7 @@ Kubernetes 提供了内置的签名者，每个签名者都有一个众所周知
|
|||
{{< glossary_tooltip term_id="kube-controller-manager" >}} 可以自动批准它。
|
||||
|
||||
1. 信任分发：签名的证书将被 API 服务器视为客户端证书，CA 证书包不通过任何其他方式分发。
|
||||
1. 许可的主体：组织名必须是 `["system:nodes"]`，用户名以 "`system:node:`" 开头
|
||||
1. 许可的主体：组织名必须是 `["system:nodes"]`，通用名称为 "`system:node:${NODE_NAME}`" 开头
|
||||
1. 许可的 x509 扩展：允许 key usage 扩展，禁用 subjectAltName 扩展，并删除其他扩展。
|
||||
1. 许可的密钥用途：`["key encipherment", "digital signature", "client auth"]`
|
||||
或 `["digital signature", "client auth"]`。
|
||||
|
|
@ -369,7 +371,7 @@ Kubernetes 提供了内置的签名者，每个签名者都有一个众所周知
|
|||
Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
|
||||
1. Trust distribution: signed certificates must be honored by the API server as valid to terminate connections to a kubelet.
|
||||
The CA bundle is not distributed by any other means.
|
||||
1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name starts with "`system:node:`".
|
||||
1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name is "`system:node:${NODE_NAME}`".
|
||||
1. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and
|
||||
URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present.
|
||||
1. Permitted key usages - `["key encipherment", "digital signature", "server auth"]` or `["digital signature", "server auth"]`.
|
||||
|
|
@ -380,7 +382,7 @@ Kubernetes 提供了内置的签名者，每个签名者都有一个众所周知
|
|||
3. `kubernetes.io/kubelet-serving`：签名服务端证书，该服务证书被 API 服务器视为有效的 kubelet 服务端证书，
|
||||
但没有其他保证。{{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。
|
||||
1. 信任分发：签名的证书必须被 kube-apiserver 认可，可有效的中止 kubelet 连接，CA 证书包不通过任何其他方式分发。
|
||||
1. 许可的主体：组织名必须是 `["system:nodes"]`，用户名以 "`system:node:`" 开头
|
||||
1. 许可的主体：组织名必须是 `["system:nodes"]`，通用名称为 "`system:node:${NODE_NAME}`" 开头
|
||||
1. 许可的 x509 扩展：允许 key usage、DNSName/IPAddress subjectAltName 等扩展，
|
||||
禁止 EmailAddress、URI subjectAltName 等扩展，并丢弃其他扩展。
|
||||
至少有一个 DNS 或 IP 的 SubjectAltName 存在。
|
||||
|
|
@ -909,11 +911,14 @@ openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"
|
|||
<!--
|
||||
### Create a CertificateSigningRequest {#create-certificatessigningrequest}
|
||||
|
||||
Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest.
|
||||
Create a [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
|
||||
and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the
|
||||
CertificateSigningRequest. a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest.
|
||||
-->
|
||||
### 创建 CertificateSigningRequest {#create-certificatesigningrequest}
|
||||
|
||||
创建一个 CertificateSigningRequest，并通过 kubectl 将其提交到 Kubernetes 集群。
|
||||
创建一个 [CertificateSigningRequest](/zh-cn/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)，
|
||||
并通过 kubectl 将其提交到 Kubernetes 集群。
|
||||
下面是生成 CertificateSigningRequest 的脚本。
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -2107,7 +2107,7 @@ Examples:
|
|||
|
||||
Default RBAC policies grant scoped permissions to control-plane components, nodes,
|
||||
and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace
|
||||
(beyond discovery permissions given to all authenticated users).
|
||||
(beyond the permissions given by [API discovery roles](#discovery-roles)).
|
||||
|
||||
This allows you to grant particular roles to particular ServiceAccounts as needed.
|
||||
Fine-grained role bindings provide greater security, but require more effort to administrate.
|
||||
|
|
@ -2118,7 +2118,7 @@ ServiceAccounts, but are easier to administrate.
|
|||
|
||||
默认的 RBAC 策略为控制面组件、节点和控制器授予权限。
|
||||
但是不会对 `kube-system` 名字空间之外的服务账户授予权限。
|
||||
（除了授予所有已认证用户的发现权限）
|
||||
（除了 [API 发现角色](#discovery-roles) 授予的权限）
|
||||
|
||||
这使得你可以根据需要向特定 ServiceAccount 授予特定权限。
|
||||
细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。
|
||||
|
|
@ -2320,13 +2320,13 @@ service accounts.
|
|||
<!--
|
||||
Default RBAC policies grant scoped permissions to control-plane components, nodes,
|
||||
and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace
|
||||
(beyond discovery permissions given to all authenticated users).
|
||||
(beyond the permissions given by [API discovery roles](#discovery-roles)).
|
||||
|
||||
While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions.
|
||||
Here are two approaches for managing this transition:
|
||||
-->
|
||||
默认的 RBAC 策略为控制面组件、节点和控制器等授予有限的权限，但不会为
|
||||
`kube-system` 名字空间外的服务账户授权（除了授予所有认证用户的发现权限之外）。
|
||||
`kube-system` 名字空间外的服务账户授权（除了 [API 发现角色](#discovery-roles)授予的权限）。
|
||||
|
||||
这样做虽然安全得多，但可能会干扰期望自动获得 API 权限的现有工作负载。
|
||||
这里有两种方法来完成这种转换:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: PortForwardWebsockets
|
||||
content_type: feature_gate
|
||||
_build:
|
||||
list: never
|
||||
render: false
|
||||
|
||||
stages:
|
||||
- stage: alpha
|
||||
defaultValue: false
|
||||
fromVersion: "1.30"
|
||||
---
|
||||
|
||||
<!--
|
||||
Allow WebSocket streaming of the
|
||||
portforward sub-protocol (`port-forward`) from clients requesting
|
||||
version v2 (`v2.portforward.k8s.io`) of the sub-protocol.
|
||||
-->
|
||||
允许从请求 v2 子协议（`v2.portforward.k8s.io`）的客户端通过 portforward 子协议
|
||||
（`port-forward`）执行 WebSocket 流式传输。
|
||||
|
|
@ -1986,6 +1986,36 @@ The label's value is in the format "MajorVersion.MinorVersion.BuildNumber".
|
|||
|
||||
标签的值采用 “MajorVersion.MinorVersion.BuildNumber” 格式。
|
||||
|
||||
<!--
|
||||
### storage.alpha.kubernetes.io/migrated-plugins {#storagealphakubernetesiomigrated-plugins}
|
||||
|
||||
Type: Annotation
|
||||
|
||||
Example:`storage.alpha.kubernetes.io/migrated-plugins: "kubernetes.io/cinder"`
|
||||
|
||||
Used on: CSINode (an extension API)
|
||||
|
||||
This annotation is automatically added for the CSINode object that maps to a node that
|
||||
installs CSIDriver. This annotation shows the in-tree plugin name of the migrated plugin. Its
|
||||
value depends on your cluster's in-tree cloud provider storage type.
|
||||
|
||||
For example, if the in-tree cloud provider storage type is `CSIMigrationvSphere`, the CSINodes instance for the node should be updated with:
|
||||
`storage.alpha.kubernetes.io/migrated-plugins: "kubernetes.io/vsphere-volume"`
|
||||
-->
|
||||
### storage.alpha.kubernetes.io/migrated-plugins {#storagealphakubernetesiomigrated-plugins}
|
||||
|
||||
类型：注解
|
||||
|
||||
例子：`storage.alpha.kubernetes.io/migrated-plugins: "kubernetes.io/cinder"`
|
||||
|
||||
用于：CSINode（一个扩展 API）
|
||||
|
||||
系统会自动为映射到安装 CSIDriver 的节点的 CSINode 对象添加此注解。
|
||||
此注解显示已迁移插件的树内插件名称，其值取决于集群的树内云驱动存储类型。
|
||||
|
||||
例如，如果树内云驱动存储类型为 `CSIMigrationvSphere`，则此节点的 CSINode 实例应更新为：
|
||||
`storage.alpha.kubernetes.io/migerated-plugins: "kubernetes.io/vsphere-volume"`
|
||||
|
||||
<!--
|
||||
### service.kubernetes.io/headless {#servicekubernetesioheadless}
|
||||
|
||||
|
|
|
|||
|
|
@ -292,10 +292,10 @@ spec:
|
|||
```
|
||||
|
||||
<!--
|
||||
This pod runs in the `BestEffort` QoS class because no resource `requests` or
|
||||
The pod above runs in the `BestEffort` QoS class because no resource `requests` or
|
||||
`limits` are specified. It runs in the shared pool.
|
||||
-->
|
||||
该 Pod 属于 `BestEffort` QoS 类型，因为其未指定 `requests` 或 `limits` 值。
|
||||
上例的 Pod 属于 `BestEffort` QoS 类，因为其未指定 `requests` 或 `limits` 值。
|
||||
所以该容器运行在共享 CPU 池中。
|
||||
|
||||
```yaml
|
||||
|
|
@ -311,11 +311,11 @@ spec:
|
|||
```
|
||||
|
||||
<!--
|
||||
This pod runs in the `Burstable` QoS class because resource `requests` do not
|
||||
The pod above runs in the `Burstable` QoS class because resource `requests` do not
|
||||
equal `limits` and the `cpu` quantity is not specified. It runs in the shared
|
||||
pool.
|
||||
-->
|
||||
该 Pod 属于 `Burstable` QoS 类型，因为其资源 `requests` 不等于 `limits`，且未指定 `cpu` 数量。
|
||||
上例的 Pod 属于 `Burstable` QoS 类，因为其资源 `requests` 不等于 `limits`，且未指定 `cpu` 数量。
|
||||
所以该容器运行在共享 CPU 池中。
|
||||
|
||||
```yaml
|
||||
|
|
@ -333,10 +333,10 @@ spec:
|
|||
```
|
||||
|
||||
<!--
|
||||
This pod runs in the `Burstable` QoS class because resource `requests` do not
|
||||
The pod above runs in the `Burstable` QoS class because resource `requests` do not
|
||||
equal `limits`. It runs in the shared pool.
|
||||
-->
|
||||
该 Pod 属于 `Burstable` QoS 类型，因为其资源 `requests` 不等于 `limits`。
|
||||
上例的 Pod 属于 `Burstable` QoS 类，因为其资源 `requests` 不等于 `limits`。
|
||||
所以该容器运行在共享 CPU 池中。
|
||||
|
||||
```yaml
|
||||
|
|
@ -354,11 +354,11 @@ spec:
|
|||
```
|
||||
|
||||
<!--
|
||||
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
The pod above runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
And the container's resource limit for the CPU resource is an integer greater than
|
||||
or equal to one. The `nginx` container is granted 2 exclusive CPUs.
|
||||
-->
|
||||
该 Pod 属于 `Guaranteed` QoS 类型，因为其 `requests` 值与 `limits`相等。
|
||||
上例的 Pod 属于 `Guaranteed` QoS 类，因为其 `requests` 值与 `limits` 相等。
|
||||
同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。
|
||||
所以，该 `nginx` 容器被赋予 2 个独占 CPU。
|
||||
|
||||
|
|
@ -377,11 +377,11 @@ spec:
|
|||
```
|
||||
|
||||
<!--
|
||||
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
The pod above runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
But the container's resource limit for the CPU resource is a fraction. It runs in
|
||||
the shared pool.
|
||||
-->
|
||||
该 Pod 属于 `Guaranteed` QoS 类型，因为其 `requests` 值与 `limits`相等。
|
||||
上例的 Pod 属于 `Guaranteed` QoS 类，因为其 `requests` 值与 `limits` 相等。
|
||||
但是容器对 CPU 资源的限制值是一个小数。所以该容器运行在共享 CPU 池中。
|
||||
|
||||
```yaml
|
||||
|
|
@ -396,12 +396,12 @@ spec:
|
|||
```
|
||||
|
||||
<!--
|
||||
This pod runs in the `Guaranteed` QoS class because only `limits` are specified
|
||||
The pod above runs in the `Guaranteed` QoS class because only `limits` are specified
|
||||
and `requests` are set equal to `limits` when not explicitly specified. And the
|
||||
container's resource limit for the CPU resource is an integer greater than or
|
||||
equal to one. The `nginx` container is granted 2 exclusive CPUs.
|
||||
-->
|
||||
该 Pod 属于 `Guaranteed` QoS 类型，因其指定了 `limits` 值，同时当未显式指定时，
|
||||
上例的 Pod 属于 `Guaranteed` QoS 类，因其指定了 `limits` 值，同时当未显式指定时，
|
||||
`requests` 值被设置为与 `limits` 值相等。
|
||||
同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。
|
||||
所以，该 `nginx` 容器被赋予 2 个独占 CPU。
|
||||
|
|
|
|||
|
|
@ -33,16 +33,16 @@ Secret 和 ConfigMap。你可以使用 Kustomize 创建**资源生成器（Resou
|
|||
|
||||
You can generate a Secret by defining a `secretGenerator` in a
|
||||
`kustomization.yaml` file that references other existing files, `.env` files, or
|
||||
literal values. For example, the following instructions create a Kustomization
|
||||
literal values. For example, the following instructions create a kustomization
|
||||
file for the username `admin` and the password `1f2d1e2e67df`.
|
||||
|
||||
### Create the Kustomization file
|
||||
### Create the kustomization file
|
||||
-->
|
||||
## 创建 Secret {#create-a-secret}
|
||||
|
||||
你可以在 `kustomization.yaml` 文件中定义 `secreteGenerator` 字段，
|
||||
并在定义中引用其它本地文件、`.env` 文件或文字值生成 Secret。
|
||||
例如：下面的指令为用户名 `admin` 和密码 `1f2d1e2e67df` 创建 Kustomization 文件。
|
||||
例如：下面的指令为用户名 `admin` 和密码 `1f2d1e2e67df` 创建 kustomization 文件。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
|
|
@ -51,7 +51,7 @@ The `stringData` field for a Secret does not work well with server-side apply.
|
|||
Secret 的 `stringData` 字段与服务端应用不兼容。
|
||||
{{< /note >}}
|
||||
|
||||
### 创建 Kustomization 文件 {#create-the-kustomization-file}
|
||||
### 创建 kustomization 文件 {#create-the-kustomization-file}
|
||||
|
||||
{{< tabs name="Secret data" >}}
|
||||
{{< tab name="文字" codelang="yaml" >}}
|
||||
|
|
@ -93,7 +93,7 @@ secretGenerator:
|
|||
- password.txt
|
||||
```
|
||||
|
||||
{{% /tab %}}}
|
||||
{{% /tab %}}
|
||||
{{% tab name=".env 文件" %}}
|
||||
<!--
|
||||
You can also define the secretGenerator in the `kustomization.yaml` file by
|
||||
|
|
@ -113,7 +113,7 @@ secretGenerator:
|
|||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
In all cases, you don't need to base64 encode the values. The name of the YAML
|
||||
In all cases, you don't need to encode the values in base64. The name of the YAML
|
||||
file **must** be `kustomization.yaml` or `kustomization.yml`.
|
||||
-->
|
||||
在所有情况下，你都不需要对取值作 base64 编码。
|
||||
|
|
@ -147,6 +147,10 @@ the Secret data and appending the hash value to the name. This ensures that
|
|||
a new Secret is generated each time the data is modified.
|
||||
|
||||
To verify that the Secret was created and to decode the Secret data,
|
||||
|
||||
```shell
|
||||
kubectl get -k <directory-path> -o jsonpath='{.data}'
|
||||
```
|
||||
-->
|
||||
生成 Secret 时，Secret 的名称最终是由 `name` 字段和数据的哈希值拼接而成。
|
||||
这将保证每次修改数据时生成一个新的 Secret。
|
||||
|
|
@ -154,7 +158,7 @@ To verify that the Secret was created and to decode the Secret data,
|
|||
要验证 Secret 是否已创建并解码 Secret 数据，
|
||||
|
||||
```shell
|
||||
kubectl get -k <directory-path> -o jsonpath='{.data}'
|
||||
kubectl get -k <目录路径> -o jsonpath='{.data}'
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
@ -163,11 +167,11 @@ The output is similar to:
|
|||
输出类似于：
|
||||
|
||||
```
|
||||
{ "password": "UyFCXCpkJHpEc2I9", "username": "YWRtaW4=" }
|
||||
````
|
||||
{ "password": "MWYyZDFlMmU2N2Rm", "username": "YWRtaW4=" }
|
||||
```
|
||||
|
||||
```
|
||||
echo 'UyFCXCpkJHpEc2I9' | base64 --decode
|
||||
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
@ -176,7 +180,7 @@ The output is similar to:
|
|||
输出类似于：
|
||||
|
||||
```
|
||||
S!B\*d$zDsb=
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
@ -193,6 +197,10 @@ For more information, refer to
|
|||
|
||||
1. In your `kustomization.yaml` file, modify the data, such as the `password`.
|
||||
1. Apply the directory that contains the kustomization file:
|
||||
|
||||
```shell
|
||||
kubectl apply -k <directory-path>
|
||||
```
|
||||
-->
|
||||
## 编辑 Secret {#edit-secret}
|
||||
|
||||
|
|
|
|||
|
|
@ -1192,7 +1192,7 @@ Kubernetes {{< skew currentVersion >}} 下实现的验证逐步升级不支持
|
|||
|
||||
<!--
|
||||
- `x-kubernetes-validations`
|
||||
For Kubernetes 1.28, CRD validation rules](#validation-rules) are ignored by
|
||||
For Kubernetes 1.28, CRD [validation rules](#validation-rules) are ignored by
|
||||
ratcheting. Starting with Alpha 2 in Kubernetes 1.29, `x-kubernetes-validations`
|
||||
are ratcheted only if they do not refer to `oldSelf`.
|
||||
|
||||
|
|
@ -2630,6 +2630,77 @@ The `NAME` column is implicit and does not need to be defined in the CustomResou
|
|||
`NAME` 列是隐含的，不需要在 CustomResourceDefinition 中定义。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
#### Priority
|
||||
|
||||
Each column includes a `priority` field. Currently, the priority
|
||||
differentiates between columns shown in standard view or wide view (using the `-o wide` flag).
|
||||
|
||||
- Columns with priority `0` are shown in standard view.
|
||||
- Columns with priority greater than `0` are shown only in wide view.
|
||||
-->
|
||||
#### 优先级 {#priority}
|
||||
|
||||
每个列都包含一个 `priority`（优先级）字段。当前，优先级用来区分标准视图（Standard
|
||||
View）和宽视图（Wide View）（使用 `-o wide` 标志）中显示的列：
|
||||
|
||||
- 优先级为 `0` 的列会在标准视图中显示。
|
||||
- 优先级大于 `0` 的列只会在宽视图中显示。
|
||||
|
||||
<!--
|
||||
#### Type
|
||||
|
||||
A column's `type` field can be any of the following (compare
|
||||
[OpenAPI v3 data types](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)):
|
||||
|
||||
- `integer` – non-floating-point numbers
|
||||
- `number` – floating point numbers
|
||||
- `string` – strings
|
||||
- `boolean` – `true` or `false`
|
||||
- `date` – rendered differentially as time since this timestamp.
|
||||
-->
|
||||
#### 类型 {#type}
|
||||
|
||||
列的 `type` 字段可以是以下值之一
|
||||
（比较 [OpenAPI v3 数据类型](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)）：
|
||||
|
||||
- `integer` – 非浮点数字
|
||||
- `number` – 浮点数字
|
||||
- `string` – 字符串
|
||||
- `boolean` – `true` 或 `false`
|
||||
- `date` – 显示为以自此时间戳以来经过的时长
|
||||
|
||||
<!--
|
||||
If the value inside a CustomResource does not match the type specified for the column,
|
||||
the value is omitted. Use CustomResource validation to ensure that the value
|
||||
types are correct.
|
||||
-->
|
||||
如果 CustomResource 中的值与列中指定的类型不匹配，该值会被忽略。
|
||||
你可以通过 CustomResource 的合法性检查来确保取值类型是正确的。
|
||||
|
||||
<!--
|
||||
#### Format
|
||||
|
||||
A column's `format` field can be any of the following:
|
||||
-->
|
||||
#### 格式 {#format}
|
||||
|
||||
列的 `format` 字段可以是以下值之一：
|
||||
|
||||
- `int32`
|
||||
- `int64`
|
||||
- `float`
|
||||
- `double`
|
||||
- `byte`
|
||||
- `date`
|
||||
- `date-time`
|
||||
- `password`
|
||||
|
||||
<!--
|
||||
The column's `format` controls the style used when `kubectl` prints the value.
|
||||
-->
|
||||
列的 `format` 字段控制 `kubectl` 打印对应取值时采用的风格。
|
||||
|
||||
<!--
|
||||
### Field selectors
|
||||
|
||||
|
|
@ -2772,77 +2843,6 @@ NAME COLOR SIZE
|
|||
example2 blue M
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Priority
|
||||
|
||||
Each column includes a `priority` field. Currently, the priority
|
||||
differentiates between columns shown in standard view or wide view (using the `-o wide` flag).
|
||||
|
||||
- Columns with priority `0` are shown in standard view.
|
||||
- Columns with priority greater than `0` are shown only in wide view.
|
||||
-->
|
||||
#### 优先级 {#priority}
|
||||
|
||||
每个列都包含一个 `priority`（优先级）字段。当前，优先级用来区分标准视图（Standard
|
||||
View）和宽视图（Wide View）（使用 `-o wide` 标志）中显示的列：
|
||||
|
||||
- 优先级为 `0` 的列会在标准视图中显示。
|
||||
- 优先级大于 `0` 的列只会在宽视图中显示。
|
||||
|
||||
<!--
|
||||
#### Type
|
||||
|
||||
A column's `type` field can be any of the following (compare
|
||||
[OpenAPI v3 data types](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)):
|
||||
|
||||
- `integer` – non-floating-point numbers
|
||||
- `number` – floating point numbers
|
||||
- `string` – strings
|
||||
- `boolean` – `true` or `false`
|
||||
- `date` – rendered differentially as time since this timestamp.
|
||||
-->
|
||||
#### 类型 {#type}
|
||||
|
||||
列的 `type` 字段可以是以下值之一
|
||||
（比较 [OpenAPI v3 数据类型](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)）：
|
||||
|
||||
- `integer` – 非浮点数字
|
||||
- `number` – 浮点数字
|
||||
- `string` – 字符串
|
||||
- `boolean` – `true` 或 `false`
|
||||
- `date` – 显示为以自此时间戳以来经过的时长
|
||||
|
||||
<!--
|
||||
If the value inside a CustomResource does not match the type specified for the column,
|
||||
the value is omitted. Use CustomResource validation to ensure that the value
|
||||
types are correct.
|
||||
-->
|
||||
如果定制资源中的值与列中指定的类型不匹配，该值会被忽略。
|
||||
你可以通过定制资源的合法性检查来确保取值类型是正确的。
|
||||
|
||||
<!--
|
||||
#### Format
|
||||
|
||||
A column's `format` field can be any of the following:
|
||||
-->
|
||||
#### 格式 {#format}
|
||||
|
||||
列的 `format` 字段可以是以下值之一：
|
||||
|
||||
- `int32`
|
||||
- `int64`
|
||||
- `float`
|
||||
- `double`
|
||||
- `byte`
|
||||
- `date`
|
||||
- `date-time`
|
||||
- `password`
|
||||
|
||||
<!--
|
||||
The column's `format` controls the style used when `kubectl` prints the value.
|
||||
-->
|
||||
列的 `format` 字段控制 `kubectl` 打印对应取值时采用的风格。
|
||||
|
||||
<!--
|
||||
### Subresources
|
||||
|
||||
|
|
|
|||
|
|
@ -244,9 +244,16 @@ Deployment 是管理 Pod 创建和扩展的推荐方法。
|
|||
```
|
||||
|
||||
<!--
|
||||
1. View application logs for a container in a pod.
|
||||
1. View application logs for a container in a pod (replace pod name with the one you got from `kubectl get pods`).
|
||||
-->
|
||||
1. 查看 Pod 中容器的应用程序日志。
|
||||
1. 查看 Pod 中容器的应用程序日志（将 Pod 名称替换为你用 `kubectl get pods` 命令获得的名称）。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Replace `hello-node-5f76cf6ccf-br9b5` in the `kubectl logs` command with the name of the pod from the `kubectl get pods` command output.
|
||||
-->
|
||||
将 `kubectl logs` 命令中的 `hello-node-5f76cf6ccf-br9b5` 替换为 `kubectl get pods` 命令输出中的 Pod 名称。
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
kubectl logs hello-node-5f76cf6ccf-br9b5
|
||||
|
|
@ -283,6 +290,16 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
|
|||
要使得 `hello-node` 容器可以从 Kubernetes 虚拟网络的外部访问，你必须将 Pod
|
||||
通过 Kubernetes [**Service**](/zh-cn/docs/concepts/services-networking/service/) 公开出来。
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
The agnhost container has a `/shell` endpoint, which is useful for
|
||||
debugging, but dangerous to expose to the public internet. Do not run this on an
|
||||
internet-facing cluster, or a production cluster.
|
||||
-->
|
||||
agnhost 容器有一个 `/shell` 端点，对于调试很有帮助，但暴露给公共互联网很危险。
|
||||
请勿在面向互联网的集群或生产集群上运行它。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
1. Expose the Pod to the public internet using the `kubectl expose` command:
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -154,9 +154,9 @@ Where `<profile_type>` is one of:
|
|||
* `Unconfined` 无需 AppArmor 即可运行
|
||||
|
||||
<!--
|
||||
See the [API Reference](#api-reference) for the full details on the AppArmor profile API.
|
||||
See [Specifying AppArmor Confinement](#specifying-apparmor-confinement) for full details on the AppArmor profile API.
|
||||
-->
|
||||
有关 AppArmor 配置文件 API 的完整详细信息，请参阅 [API 参考](#api-reference)。
|
||||
有关 AppArmor 配置文件 API 的完整详细信息，请参阅[指定 AppArmor 限制](#specifying-apparmor-confinement)。
|
||||
|
||||
<!--
|
||||
To verify that the profile was applied, you can check that the container's root process is
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@ apiVersion: networking.k8s.io/v1
|
|||
kind: Ingress
|
||||
metadata:
|
||||
name: example-ingress
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
ingressClassName: nginx
|
||||
rules:
|
||||
|
|
|
|||
|
|
@ -4,6 +4,9 @@
|
|||
# schedule-builder -uc data/releases/schedule.yaml -e data/releases/eol.yaml
|
||||
---
|
||||
branches:
|
||||
- endOfLifeDate: "2024-07-16"
|
||||
finalPatchRelease: 1.27.16
|
||||
release: "1.27"
|
||||
- endOfLifeDate: "2024-02-28"
|
||||
finalPatchRelease: 1.26.15
|
||||
note: 1.26.15 was released in March 2024 (after the EOL date) to pick up a new version
|
||||
|
|
|
|||
|
|
@ -7,10 +7,13 @@ schedules:
|
|||
- endOfLifeDate: "2025-06-28"
|
||||
maintenanceModeStartDate: "2025-04-28"
|
||||
next:
|
||||
cherryPickDeadline: "2024-07-12"
|
||||
cherryPickDeadline: "2024-08-09"
|
||||
release: 1.30.4
|
||||
targetDate: "2024-08-13"
|
||||
previousPatches:
|
||||
- cherryPickDeadline: "2024-07-12"
|
||||
release: 1.30.3
|
||||
targetDate: "2024-07-16"
|
||||
previousPatches:
|
||||
- cherryPickDeadline: "2024-06-07"
|
||||
release: 1.30.2
|
||||
targetDate: "2024-06-11"
|
||||
|
|
@ -24,10 +27,13 @@ schedules:
|
|||
- endOfLifeDate: "2025-02-28"
|
||||
maintenanceModeStartDate: "2024-12-28"
|
||||
next:
|
||||
cherryPickDeadline: "2024-07-12"
|
||||
cherryPickDeadline: "2024-08-09"
|
||||
release: 1.29.8
|
||||
targetDate: "2024-08-13"
|
||||
previousPatches:
|
||||
- cherryPickDeadline: "2024-07-12"
|
||||
release: 1.29.7
|
||||
targetDate: "2024-07-16"
|
||||
previousPatches:
|
||||
- cherryPickDeadline: "2024-06-07"
|
||||
release: 1.29.6
|
||||
targetDate: "2024-06-11"
|
||||
|
|
@ -53,10 +59,13 @@ schedules:
|
|||
- endOfLifeDate: "2024-10-28"
|
||||
maintenanceModeStartDate: "2024-08-28"
|
||||
next:
|
||||
cherryPickDeadline: "2024-07-12"
|
||||
cherryPickDeadline: "2024-08-09"
|
||||
release: 1.28.13
|
||||
targetDate: "2024-08-13"
|
||||
previousPatches:
|
||||
- cherryPickDeadline: "2024-07-12"
|
||||
release: 1.28.12
|
||||
targetDate: "2024-07-16"
|
||||
previousPatches:
|
||||
- cherryPickDeadline: "2024-06-07"
|
||||
release: 1.28.11
|
||||
targetDate: "2024-06-11"
|
||||
|
|
@ -95,66 +104,10 @@ schedules:
|
|||
targetDate: "2023-08-15"
|
||||
release: "1.28"
|
||||
releaseDate: "2023-08-15"
|
||||
- endOfLifeDate: "2024-06-28"
|
||||
maintenanceModeStartDate: "2024-04-28"
|
||||
next:
|
||||
cherryPickDeadline: "2024-07-12"
|
||||
release: 1.27.16
|
||||
targetDate: "2024-07-16"
|
||||
previousPatches:
|
||||
- cherryPickDeadline: "2024-06-07"
|
||||
release: 1.27.15
|
||||
targetDate: "2024-06-11"
|
||||
- cherryPickDeadline: "2024-05-10"
|
||||
release: 1.27.14
|
||||
targetDate: "2024-05-14"
|
||||
- cherryPickDeadline: "2024-04-12"
|
||||
release: 1.27.13
|
||||
targetDate: "2024-04-16"
|
||||
- cherryPickDeadline: "2024-03-08"
|
||||
release: 1.27.12
|
||||
targetDate: "2024-03-13"
|
||||
- cherryPickDeadline: "2024-02-09"
|
||||
release: 1.27.11
|
||||
targetDate: "2024-02-14"
|
||||
- cherryPickDeadline: "2023-01-12"
|
||||
release: 1.27.10
|
||||
targetDate: "2024-01-17"
|
||||
- cherryPickDeadline: "2023-12-15"
|
||||
release: 1.27.9
|
||||
targetDate: "2023-12-20"
|
||||
- note: Out of band release to fix [CVE-2023-5528](https://groups.google.com/g/kubernetes-announce/c/c3py6Fw0DTI/m/cScFSdk1BwAJ)
|
||||
release: 1.27.8
|
||||
targetDate: "2023-11-14"
|
||||
- cherryPickDeadline: "2023-10-13"
|
||||
release: 1.27.7
|
||||
targetDate: "2023-10-18"
|
||||
- cherryPickDeadline: "2023-09-08"
|
||||
release: 1.27.6
|
||||
targetDate: "2023-09-13"
|
||||
- cherryPickDeadline: "2023-08-04"
|
||||
release: 1.27.5
|
||||
targetDate: "2023-08-23"
|
||||
- cherryPickDeadline: "2023-07-14"
|
||||
release: 1.27.4
|
||||
targetDate: "2023-07-19"
|
||||
- cherryPickDeadline: "2023-06-09"
|
||||
release: 1.27.3
|
||||
targetDate: "2023-06-14"
|
||||
- cherryPickDeadline: "2023-05-12"
|
||||
release: 1.27.2
|
||||
targetDate: "2023-05-17"
|
||||
- note: '[Regression](https://groups.google.com/g/kubernetes-announce/c/9FTKjmIFOTw/m/TH6cJT64AAAJ)'
|
||||
release: 1.27.1
|
||||
targetDate: "2023-04-14"
|
||||
- release: 1.27.0
|
||||
targetDate: "2023-04-11"
|
||||
release: "1.27"
|
||||
releaseDate: "2023-04-11"
|
||||
upcoming_releases:
|
||||
- cherryPickDeadline: "2024-07-12"
|
||||
targetDate: "2024-07-16"
|
||||
- cherryPickDeadline: "2024-08-09"
|
||||
targetDate: "2024-08-13"
|
||||
- cherryPickDeadline: "2024-09-06"
|
||||
targetDate: "2024-09-10"
|
||||
- cherryPickDeadline: "2024-10-11"
|
||||
targetDate: "2024-10-15"
|
||||
|
|
|
|||
Loading…
Reference in New Issue