Merge master into dev-1.21 to keep in sync - SIG-Release 1.21 Docs team 2/19/21
This commit is contained in:
Rey Lejano
@@ -205,8 +205,10 @@ spec:
|
||||
```
|
||||
|
||||
Service account bearer tokens are perfectly valid to use outside the cluster and
|
||||
|
||||
can be used to create identities for long standing jobs that wish to talk to the
|
||||
Kubernetes API. To manually create a service account, use the `kubectl
|
||||
Kubernetes API. To manually create a service account, simply use the `kubectl`
|
||||
|
||||
create serviceaccount (NAME)` command. This creates a service account in the
|
||||
current namespace and an associated secret.
|
||||
|
||||
@@ -320,6 +322,7 @@ sequenceDiagram
|
||||
8. Once authorized the API server returns a response to `kubectl`
|
||||
9. `kubectl` provides feedback to the user
|
||||
|
||||
|
||||
Since all of the data needed to validate who you are is in the `id_token`, Kubernetes doesn't need to
|
||||
"phone home" to the identity provider. In a model where every request is stateless this provides a very scalable solution for authentication. It does offer a few challenges:
|
||||
|
||||
@@ -731,7 +734,7 @@ to the impersonated user info.
|
||||
The following HTTP headers can be used to performing an impersonation request:
|
||||
|
||||
* `Impersonate-User`: The username to act as.
|
||||
* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User"
|
||||
* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User".
|
||||
* `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. Optional. Requires "Impersonate-User". In order to be preserved consistently, `( extra name )` should be lower-case, and any characters which aren't [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6) MUST be utf8 and [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1).
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -352,7 +352,7 @@ different Kubernetes components.
|
||||
| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `VolumeScheduling` | `true` | GA | 1.13 | - |
|
||||
| `VolumeSubpath` | `true` | GA | 1.13 | - |
|
||||
| `VolumeSubpath` | `true` | GA | 1.10 | - |
|
||||
| `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | 1.16 |
|
||||
| `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - |
|
||||
|
||||
@@ -17,6 +17,6 @@ tags:
|
||||
Their primary responsibility is keeping a cluster up and running, which may involve periodic maintenance activities or upgrades.<br>
|
||||
|
||||
{{< note >}}
|
||||
Cluster operators are different from the [Operator pattern](https://coreos.com/operators) that extends the Kubernetes API.
|
||||
Cluster operators are different from the [Operator pattern](https://www.openshift.com/learn/topics/operators) that extends the Kubernetes API.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -114,3 +114,143 @@ The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure tha
|
||||
If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider
|
||||
adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
|
||||
|
||||
## node.kubernetes.io/windows-build {#nodekubernetesiowindows-build}
|
||||
|
||||
Example: `node.kubernetes.io/windows-build=10.0.17763`
|
||||
|
||||
Used on: Node
|
||||
|
||||
When the kubelet is running on Microsoft Windows, it automatically labels its node to record the version of Windows Server in use.
|
||||
|
||||
The label's value is in the format "MajorVersion.MinorVersion.BuildNumber".
|
||||
|
||||
## service.kubernetes.io/headless {#servicekubernetesioheadless}
|
||||
|
||||
Example: `service.kubernetes.io/headless=""`
|
||||
|
||||
Used on: Service
|
||||
|
||||
The control plane adds this label to an Endpoints object when the owning Service is headless.
|
||||
|
||||
## kubernetes.io/service-name {#kubernetesioservice-name}
|
||||
|
||||
Example: `kubernetes.io/service-name="nginx"`
|
||||
|
||||
Used on: Service
|
||||
|
||||
Kubernetes uses this label to differentiate multiple Services. Used currently for `ELB`(Elastic Load Balancer) only.
|
||||
|
||||
## endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by}
|
||||
|
||||
Example: `endpointslice.kubernetes.io/managed-by="controller"`
|
||||
|
||||
Used on: EndpointSlices
|
||||
|
||||
The label is used to indicate the controller or entity that manages an EndpointSlice. This label aims to enable different EndpointSlice objects to be managed by different controllers or entities within the same cluster.
|
||||
|
||||
## endpointslice.kubernetes.io/skip-mirror {#endpointslicekubernetesioskip-mirror}
|
||||
|
||||
Example: `endpointslice.kubernetes.io/skip-mirror="true"`
|
||||
|
||||
Used on: Endpoints
|
||||
|
||||
The label can be set to `"true"` on an Endpoints resource to indicate that the EndpointSliceMirroring controller should not mirror this resource with EndpointSlices.
|
||||
|
||||
## service.kubernetes.io/service-proxy-name {#servicekubernetesioservice-proxy-name}
|
||||
|
||||
Example: `service.kubernetes.io/service-proxy-name="foo-bar"`
|
||||
|
||||
Used on: Service
|
||||
|
||||
The kube-proxy has this label for custom proxy, which delegates service control to custom proxy.
|
||||
|
||||
## experimental.windows.kubernetes.io/isolation-type
|
||||
|
||||
Example: `experimental.windows.kubernetes.io/isolation-type: "hyperv"`
|
||||
|
||||
Used on: Pod
|
||||
|
||||
The annotation is used to run Windows containers with Hyper-V isolation. To use Hyper-V isolation feature and create a Hyper-V isolated container, the kubelet should be started with feature gates HyperVContainer=true and the Pod should include the annotation experimental.windows.kubernetes.io/isolation-type=hyperv.
|
||||
|
||||
{{< note >}}
|
||||
You can only set this annotation on Pods that have a single container.
|
||||
{{< /note >}}
|
||||
|
||||
## ingressclass.kubernetes.io/is-default-class
|
||||
|
||||
Example: `ingressclass.kubernetes.io/is-default-class: "true"`
|
||||
|
||||
Used on: IngressClass
|
||||
|
||||
When a single IngressClass resource has this annotation set to `"true"`, new Ingress resource without a class specified will be assigned this default class.
|
||||
|
||||
## kubernetes.io/ingress.class (deprecated)
|
||||
|
||||
{{< note >}} Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. {{< /note >}}
|
||||
|
||||
## alpha.kubernetes.io/provided-node-ip
|
||||
|
||||
Example: `alpha.kubernetes.io/provided-node-ip: "10.0.0.1"`
|
||||
|
||||
Used on: Node
|
||||
|
||||
The kubelet can set this annotation on a Node to denote its configured IPv4 address.
|
||||
|
||||
When kubelet is started with the "external" cloud provider, it sets this annotation on the Node to denote an IP address set from the command line flag (`--node-ip`). This IP is verified with the cloud provider as valid by the cloud-controller-manager.
|
||||
|
||||
**The taints listed below are always used on Nodes**
|
||||
|
||||
## node.kubernetes.io/not-ready
|
||||
|
||||
Example: `node.kubernetes.io/not-ready:NoExecute`
|
||||
|
||||
The node controller detects whether a node is ready by monitoring its health and adds or removes this taint accordingly.
|
||||
|
||||
## node.kubernetes.io/unreachable
|
||||
|
||||
Example: `node.kubernetes.io/unreachable:NoExecute`
|
||||
|
||||
The node controller adds the taint to a node corresponding to the [NodeCondition](/docs/concepts/architecture/nodes/#condition) `Ready` being `Unknown`.
|
||||
|
||||
## node.kubernetes.io/unschedulable
|
||||
|
||||
Example: `node.kubernetes.io/unschedulable:NoSchedule`
|
||||
|
||||
The taint will be added to a node when initializing the node to avoid race condition.
|
||||
|
||||
## node.kubernetes.io/memory-pressure
|
||||
|
||||
Example: `node.kubernetes.io/memory-pressure:NoSchedule`
|
||||
|
||||
The kubelet detects memory pressure based on `memory.available` and `allocatableMemory.available` observed on a Node. The observed values are then compared to the corresponding thresholds that can be set on the kubelet to determine if the Node condition and taint should be added/removed.
|
||||
|
||||
## node.kubernetes.io/disk-pressure
|
||||
|
||||
Example: `node.kubernetes.io/disk-pressure:NoSchedule`
|
||||
|
||||
The kubelet detects disk pressure based on `imagefs.available`, `imagefs.inodesFree`, `nodefs.available` and `nodefs.inodesFree`(Linux only) observed on a Node. The observed values are then compared to the corresponding thresholds that can be set on the kubelet to determine if the Node condition and taint should be added/removed.
|
||||
|
||||
## node.kubernetes.io/network-unavailable
|
||||
|
||||
Example: `node.kubernetes.io/network-unavailable:NoSchedule`
|
||||
|
||||
This is initially set by the kubelet when the cloud provider used indicates a requirement for additional network configuration. Only when the route on the cloud is configured properly will the taint be removed by the cloud provider.
|
||||
|
||||
## node.kubernetes.io/pid-pressure
|
||||
|
||||
Example: `node.kubernetes.io/pid-pressure:NoSchedule`
|
||||
|
||||
The kubelet checks D-value of the size of `/proc/sys/kernel/pid_max` and the PIDs consumed by Kubernetes on a node to get the number of available PIDs that referred to as the `pid.available` metric. The metric is then compared to the corresponding threshold that can be set on the kubelet to determine if the node condition and taint should be added/removed.
|
||||
|
||||
## node.cloudprovider.kubernetes.io/uninitialized
|
||||
|
||||
Example: `node.cloudprovider.kubernetes.io/uninitialized:NoSchedule`
|
||||
|
||||
Sets this taint on a node to mark it as unusable, when kubelet is started with the "external" cloud provider, until a controller from the cloud-controller-manager initializes this node, and then removes the taint.
|
||||
|
||||
## node.cloudprovider.kubernetes.io/shutdown
|
||||
|
||||
Example: `node.cloudprovider.kubernetes.io/shutdown:NoSchedule`
|
||||
|
||||
If a Node is in a cloud provider specified shutdown state, the Node gets tainted accordingly with `node.cloudprovider.kubernetes.io/shutdown` and the taint effect of `NoSchedule`.
|
||||
|
||||
|
||||
@@ -258,7 +258,7 @@ Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1, application/json
|
||||
|
||||
## Alternate representations of resources
|
||||
|
||||
By default Kubernetes returns objects serialized to JSON with content type `application/json`. This is the default serialization format for the API. However, clients may request the more efficient Protobuf representation of these objects for better performance at scale. The Kubernetes API implements standard HTTP content type negotiation: passing an `Accept` header with a `GET` call will request that the server return objects in the provided content type, while sending an object in Protobuf to the server for a `PUT` or `POST` call takes the `Content-Type` header. The server will return a `Content-Type` header if the requested format is supported, or the `406 Not acceptable` error if an invalid content type is provided.
|
||||
By default, Kubernetes returns objects serialized to JSON with content type `application/json`. This is the default serialization format for the API. However, clients may request the more efficient Protobuf representation of these objects for better performance at scale. The Kubernetes API implements standard HTTP content type negotiation: passing an `Accept` header with a `GET` call will request that the server return objects in the provided content type, while sending an object in Protobuf to the server for a `PUT` or `POST` call takes the `Content-Type` header. The server will return a `Content-Type` header if the requested format is supported, or the `406 Not acceptable` error if an invalid content type is provided.
|
||||
|
||||
See the API documentation for a list of supported content types for each API.
|
||||
|
||||
@@ -560,4 +560,4 @@ If you request a a resourceVersion outside the applicable limit then, depending
|
||||
|
||||
### Unavailable resource versions
|
||||
|
||||
Servers are not required to serve unrecognized resource versions. List and Get requests for unrecognized resource versions may wait briefly for the resource version to become available, should timeout with a `504 (Gateway Timeout)` if the provided resource versions does not become available in a resonable amount of time, and may respond with a `Retry-After` response header indicating how many seconds a client should wait before retrying the request. Currently the kube-apiserver also identifies these responses with a "Too large resource version" message. Watch requests for a unrecognized resource version may wait indefinitely (until the request timeout) for the resource version to become available.
|
||||
Servers are not required to serve unrecognized resource versions. List and Get requests for unrecognized resource versions may wait briefly for the resource version to become available, should timeout with a `504 (Gateway Timeout)` if the provided resource versions does not become available in a reasonable amount of time, and may respond with a `Retry-After` response header indicating how many seconds a client should wait before retrying the request. Currently, the kube-apiserver also identifies these responses with a "Too large resource version" message. Watch requests for an unrecognized resource version may wait indefinitely (until the request timeout) for the resource version to become available.
|
||||
|
||||
+270
@@ -0,0 +1,270 @@
|
||||
---
|
||||
reviewers:
|
||||
- liggitt
|
||||
- lavalamp
|
||||
- thockin
|
||||
- smarterclayton
|
||||
title: "Deprecated API Migration Guide"
|
||||
weight: 45
|
||||
content_type: reference
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
As the Kubernetes API evolves, APIs are periodically reorganized or upgraded.
|
||||
When APIs evolve, the old API is deprecated and eventually removed.
|
||||
This page contains information you need to know when migrating from
|
||||
deprecated API versions to newer and more stable API versions.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Removed APIs by release
|
||||
|
||||
|
||||
### v1.25
|
||||
|
||||
The **v1.25** release will stop serving the following deprecated API versions:
|
||||
|
||||
#### Event {#event-v125}
|
||||
|
||||
The **events.k8s.io/v1beta1** API version of Event will no longer be served in v1.25.
|
||||
|
||||
* Migrate manifests and API clients to use the **events.k8s.io/v1** API version, available since v1.19.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* Notable changes in **events.k8s.io/v1**:
|
||||
* `type` is limited to `Normal` and `Warning`
|
||||
* `involvedObject` is renamed to `regarding`
|
||||
* `action`, `reason`, `reportingComponent`, and `reportingInstance` are required when creating new **events.k8s.io/v1** Events
|
||||
* use `eventTime` instead of the deprecated `firstTimestamp` field (which is renamed to `deprecatedFirstTimestamp` and not permitted in new **events.k8s.io/v1** Events)
|
||||
* use `series.lastObservedTime` instead of the deprecated `lastTimestamp` field (which is renamed to `deprecatedLastTimestamp` and not permitted in new **events.k8s.io/v1** Events)
|
||||
* use `series.count` instead of the deprecated `count` field (which is renamed to `deprecatedCount` and not permitted in new **events.k8s.io/v1** Events)
|
||||
* use `reportingComponent` instead of the deprecated `source.component` field (which is renamed to `deprecatedSource.component` and not permitted in new **events.k8s.io/v1** Events)
|
||||
* use `reportingInstance` instead of the deprecated `source.host` field (which is renamed to `deprecatedSource.host` and not permitted in new **events.k8s.io/v1** Events)
|
||||
|
||||
#### RuntimeClass {#runtimeclass-v125}
|
||||
|
||||
RuntimeClass in the **node.k8s.io/v1beta1** API version will no longer be served in v1.25.
|
||||
|
||||
* Migrate manifests and API clients to use the **node.k8s.io/v1** API version, available since v1.20.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* No notable changes
|
||||
|
||||
### v1.22
|
||||
|
||||
The **v1.22** release will stop serving the following deprecated API versions:
|
||||
|
||||
#### Webhook resources {#webhook-resources-v122}
|
||||
|
||||
The **admissionregistration.k8s.io/v1beta1** API version of MutatingWebhookConfiguration and ValidatingWebhookConfiguration will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **admissionregistration.k8s.io/v1** API version, available since v1.16.
|
||||
* All existing persisted objects are accessible via the new APIs
|
||||
* Notable changes:
|
||||
* `webhooks[*].failurePolicy` default changed from `Ignore` to `Fail` for v1
|
||||
* `webhooks[*].matchPolicy` default changed from `Exact` to `Equivalent` for v1
|
||||
* `webhooks[*].timeoutSeconds` default changed from `30s` to `10s` for v1
|
||||
* `webhooks[*].sideEffects` default value is removed, and the field made required, and only `None` and `NoneOnDryRun` are permitted for v1
|
||||
* `webhooks[*].admissionReviewVersions` default value is removed and the field made required for v1 (supported versions for AdmissionReview are `v1` and `v1beta1`)
|
||||
* `webhooks[*].name` must be unique in the list for objects created via `admissionregistration.k8s.io/v1`
|
||||
|
||||
#### CustomResourceDefinition {#customresourcedefinition-v122}
|
||||
|
||||
The **apiextensions.k8s.io/v1beta1** API version of CustomResourceDefinition will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **apiextensions.k8s.io/v1** API version, available since v1.16.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* Notable changes:
|
||||
* `spec.scope` is no longer defaulted to `Namespaced` and must be explicitly specified
|
||||
* `spec.version` is removed in v1; use `spec.versions` instead
|
||||
* `spec.validation` is removed in v1; use `spec.versions[*].schema` instead
|
||||
* `spec.subresources` is removed in v1; use `spec.versions[*].subresources` instead
|
||||
* `spec.additionalPrinterColumns` is removed in v1; use `spec.versions[*].additionalPrinterColumns` instead
|
||||
* `spec.conversion.webhookClientConfig` is moved to `spec.conversion.webhook.clientConfig` in v1
|
||||
* `spec.conversion.conversionReviewVersions` is moved to `spec.conversion.webhook.conversionReviewVersions` in v1
|
||||
* `spec.versions[*].schema.openAPIV3Schema` is now required when creating v1 CustomResourceDefinition objects, and must be a [structural schema](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema)
|
||||
* `spec.preserveUnknownFields: true` is disallowed when creating v1 CustomResourceDefinition objects; it must be specified within schema definitions as `x-kubernetes-preserve-unknown-fields: true`
|
||||
* In `additionalPrinterColumns` items, the `JSONPath` field was renamed to `jsonPath` in v1 (fixes [#66531](https://github.com/kubernetes/kubernetes/issues/66531))
|
||||
|
||||
#### APIService {#apiservice-v122}
|
||||
|
||||
The **apiregistration.k8s.io/v1beta1** API version of APIService will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **apiregistration.k8s.io/v1** API version, available since v1.10.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* No notable changes
|
||||
|
||||
#### TokenReview {#tokenreview-v122}
|
||||
|
||||
The **authentication.k8s.io/v1beta1** API version of TokenReview will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **authentication.k8s.io/v1** API version, available since v1.6.
|
||||
* No notable changes
|
||||
|
||||
#### SubjectAccessReview resources {#subjectaccessreview-resources-v122}
|
||||
|
||||
The **authorization.k8s.io/v1beta1** API version of LocalSubjectAccessReview, SelfSubjectAccessReview, and SubjectAccessReview will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **authorization.k8s.io/v1** API version, available since v1.6.
|
||||
* Notable changes:
|
||||
* `spec.group` was renamed to `spec.groups` in v1 (fixes [#32709](https://github.com/kubernetes/kubernetes/issues/32709))
|
||||
|
||||
#### CertificateSigningRequest {#certificatesigningrequest-v122}
|
||||
|
||||
The **certificates.k8s.io/v1beta1** API version of CertificateSigningRequest will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **certificates.k8s.io/v1** API version, available since v1.19.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* Notable changes in `certificates.k8s.io/v1`:
|
||||
* For API clients requesting certificates:
|
||||
* `spec.signerName` is now required (see [known Kubernetes signers](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)), and requests for `kubernetes.io/legacy-unknown` are not allowed to be created via the `certificates.k8s.io/v1` API
|
||||
* `spec.usages` is now required, may not contain duplicate values, and must only contain known usages
|
||||
* For API clients approving or signing certificates:
|
||||
* `status.conditions` may not contain duplicate types
|
||||
* `status.conditions[*].status` is now required
|
||||
* `status.certificate` must be PEM-encoded, and contain only `CERTIFICATE` blocks
|
||||
|
||||
#### Lease {#lease-v122}
|
||||
|
||||
The **coordination.k8s.io/v1beta1** API version of Lease will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **coordination.k8s.io/v1** API version, available since v1.14.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* No notable changes
|
||||
|
||||
#### Ingress {#ingress-v122}
|
||||
|
||||
The **extensions/v1beta1** and **networking.k8s.io/v1beta1** API versions of Ingress will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **networking.k8s.io/v1** API version, available since v1.19.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* Notable changes:
|
||||
* `spec.backend` is renamed to `spec.defaultBackend`
|
||||
* The backend `serviceName` field is renamed to `service.name`
|
||||
* Numeric backend `servicePort` fields are renamed to `service.port.number`
|
||||
* String backend `servicePort` fields are renamed to `service.port.name`
|
||||
* `pathType` is now required for each specified path. Options are `Prefix`, `Exact`, and `ImplementationSpecific`. To match the undefined `v1beta1` behavior, use `ImplementationSpecific`.
|
||||
|
||||
#### IngressClass {#ingressclass-v122}
|
||||
|
||||
The **networking.k8s.io/v1beta1** API version of IngressClass will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **networking.k8s.io/v1** API version, available since v1.19.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* No notable changes
|
||||
|
||||
#### RBAC resources {#rbac-resources-v122}
|
||||
|
||||
The **rbac.authorization.k8s.io/v1beta1** API version of ClusterRole, ClusterRoleBinding, Role, and RoleBinding will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **rbac.authorization.k8s.io/v1** API version, available since v1.8.
|
||||
* All existing persisted objects are accessible via the new APIs
|
||||
* No notable changes
|
||||
|
||||
#### PriorityClass {#priorityclass-v122}
|
||||
|
||||
The **scheduling.k8s.io/v1beta1** API version of PriorityClass will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **scheduling.k8s.io/v1** API version, available since v1.14.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* No notable changes
|
||||
|
||||
#### Storage resources {#storage-resources-v122}
|
||||
|
||||
The **storage.k8s.io/v1beta1** API version of CSIDriver, CSINode, StorageClass, and VolumeAttachment will no longer be served in v1.22.
|
||||
|
||||
* Migrate manifests and API clients to use the **storage.k8s.io/v1** API version
|
||||
* CSIDriver is available in **storage.k8s.io/v1** since v1.19.
|
||||
* CSINode is available in **storage.k8s.io/v1** since v1.17
|
||||
* StorageClass is available in **storage.k8s.io/v1** since v1.6
|
||||
* VolumeAttachment is available in **storage.k8s.io/v1** v1.13
|
||||
* All existing persisted objects are accessible via the new APIs
|
||||
* No notable changes
|
||||
|
||||
### v1.16
|
||||
|
||||
The **v1.16** release stopped serving the following deprecated API versions:
|
||||
|
||||
#### NetworkPolicy {#networkpolicy-v116}
|
||||
|
||||
The **extensions/v1beta1** API version of NetworkPolicy is no longer served as of v1.16.
|
||||
|
||||
* Migrate manifests and API clients to use the **networking.k8s.io/v1** API version, available since v1.8.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
|
||||
#### DaemonSet {#daemonset-v116}
|
||||
|
||||
The **extensions/v1beta1** and **apps/v1beta2** API versions of DaemonSet are no longer served as of v1.16.
|
||||
|
||||
* Migrate manifests and API clients to use the **apps/v1** API version, available since v1.9.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* Notable changes:
|
||||
* `spec.templateGeneration` is removed
|
||||
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
|
||||
* `spec.updateStrategy.type` now defaults to `RollingUpdate` (the default in `extensions/v1beta1` was `OnDelete`)
|
||||
|
||||
#### Deployment {#deployment-v116}
|
||||
|
||||
The **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions of Deployment are no longer served as of v1.16.
|
||||
|
||||
* Migrate manifests and API clients to use the **apps/v1** API version, available since v1.9.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* Notable changes:
|
||||
* `spec.rollbackTo` is removed
|
||||
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
|
||||
* `spec.progressDeadlineSeconds` now defaults to `600` seconds (the default in `extensions/v1beta1` was no deadline)
|
||||
* `spec.revisionHistoryLimit` now defaults to `10` (the default in `apps/v1beta1` was `2`, the default in `extensions/v1beta1` was to retain all)
|
||||
* `maxSurge` and `maxUnavailable` now default to `25%` (the default in `extensions/v1beta1` was `1`)
|
||||
|
||||
#### StatefulSet {#statefulset-v116}
|
||||
|
||||
The **apps/v1beta1** and **apps/v1beta2** API versions of StatefulSet are no longer served as of v1.16.
|
||||
|
||||
* Migrate manifests and API clients to use the **apps/v1** API version, available since v1.9.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* Notable changes:
|
||||
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
|
||||
* `spec.updateStrategy.type` now defaults to `RollingUpdate` (the default in `apps/v1beta1` was `OnDelete`)
|
||||
|
||||
#### ReplicaSet {#replicaset-v116}
|
||||
|
||||
The **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions of ReplicaSet are no longer served as of v1.16.
|
||||
|
||||
* Migrate manifests and API clients to use the **apps/v1** API version, available since v1.9.
|
||||
* All existing persisted objects are accessible via the new API
|
||||
* Notable changes:
|
||||
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
|
||||
|
||||
## What to do
|
||||
|
||||
### Test with deprecated APIs disabled
|
||||
|
||||
You can test your clusters by starting an API server with specific API versions disabled
|
||||
to simulate upcoming removals. Add the following flag to the API server startup arguments:
|
||||
|
||||
`--runtime-config=<group>/<version>=false`
|
||||
|
||||
For example:
|
||||
|
||||
`--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1,...`
|
||||
|
||||
### Locate use of deprecated APIs
|
||||
|
||||
Use [client warnings, metrics, and audit information available in 1.19+](https://kubernetes.io/blog/2020/09/03/warnings/#deprecation-warnings)
|
||||
to locate use of deprecated APIs.
|
||||
|
||||
### Migrate to non-deprecated APIs
|
||||
|
||||
* Update custom integrations and controllers to call the non-deprecated APIs
|
||||
* Change YAML files to reference the non-deprecated APIs
|
||||
|
||||
You can use the `kubectl-convert` command (`kubectl convert` prior to v1.20)
|
||||
to automatically convert an existing object:
|
||||
|
||||
`kubectl-convert -f <file> --output-version <group>/<version>`.
|
||||
|
||||
For example, to convert an older Deployment to `apps/v1`, you can run:
|
||||
|
||||
`kubectl-convert -f ./my-deployment.yaml --output-version apps/v1`
|
||||
|
||||
Note that this may use non-ideal default values. To learn more about a specific
|
||||
resource, check the Kubernetes [API reference](/docs/reference/kubernetes-api/).
|
||||
Reference in New Issue
Block a user