Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated cherry pick of #118899: CHANGELOG-1.27: Add note for AWS in-tree provider removal #119065

Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
27 changes: 14 additions & 13 deletions CHANGELOG/CHANGELOG-1.27.md
Original file line number Diff line number Diff line change
Expand Up @@ -593,20 +593,21 @@ The cause PR is [reverted](https://github.com/kubernetes/kubernetes/pull/117194)
(The feature became GA in 1.23 and the gate was removed for all other
components several releases ago.) If you were still manually
enabling it you must stop now.' ([#116255](https://github.com/kubernetes/kubernetes/pull/116255), [@danwinship](https://github.com/danwinship))
- Give terminal phase correctly to all pods that will not be restarted.
- Give terminal phase correctly to all pods that will not be restarted.

In particular, assign Failed phase to pods which are deleted while pending. Also, assign a terminal
phase (Succeeded or Failed, depending on the exit statuses of the pod containers) to pods which
are deleted while running.

In particular, assign Failed phase to pods which are deleted while pending. Also, assign a terminal
phase (Succeeded or Failed, depending on the exit statuses of the pod containers) to pods which
are deleted while running.

This fixes the issue for jobs using pod failure policy (with JobPodFailurePolicy and PodDisruptionConditions
feature gates enabled) that their pods could get stuck in the pending phase when deleted.

Users who maintain controllers which relied on the fact that pods with RestartPolicy=Always
never enter the Succeeded phase may need to adapt their controllers. This is because as a consequence of
the change pods which use RestartPolicy=Always may end up in the Succeeded phase in two scenarios: pod
deletion and graceful node shutdown. ([#115331](https://github.com/kubernetes/kubernetes/pull/115331), [@mimowo](https://github.com/mimowo)) [SIG Cloud Provider, Node and Testing]

This fixes the issue for jobs using pod failure policy (with JobPodFailurePolicy and PodDisruptionConditions
feature gates enabled) that their pods could get stuck in the pending phase when deleted.

Users who maintain controllers which relied on the fact that pods with RestartPolicy=Always
never enter the Succeeded phase may need to adapt their controllers. This is because as a consequence of
the change pods which use RestartPolicy=Always may end up in the Succeeded phase in two scenarios: pod
deletion and graceful node shutdown. ([#115331](https://github.com/kubernetes/kubernetes/pull/115331), [@mimowo](https://github.com/mimowo)) [SIG Cloud Provider, Node and Testing]
- The in-tree cloud provider for AWS (and the EBS storage plugin) has now been removed. Please use the external cloud provider and CSI driver from https://github.com/kubernetes/cloud-provider-aws instead. ([#115838](https://github.com/kubernetes/kubernetes/pull/115838), [@torredil](https://github.com/torredil)) [SIG API Machinery, Apps, Architecture, Auth, CLI , Cloud Provider, Cluster Lifecycle, Instrumentation, Node, Release, Scheduling, Storage, and Testing]

## Changes by Kind

### Deprecation
Expand Down