Generating the name avoids all potential name collisions. It's not clear how
much of a problem that was because users can avoid them and the deterministic
names for generic ephemeral volumes have not led to reports from users. But
using generated names is not too hard either.
What makes it relatively easy is that the new pod.status.resourceClaimStatus
map stores the generated name for kubelet and node authorizer, i.e. the
information in the pod is sufficient to determine the name of the
ResourceClaim.
The resource claim controller becomes a bit more complex and now needs
permission to modify the pod status. The new failure scenario of "ResourceClaim
created, updating pod status fails" is handled with the help of a new special
"resource.kubernetes.io/pod-claim-name" annotation that together with the owner
reference identifies exactly for what a ResourceClaim was generated, so
updating the pod status can be retried for existing ResourceClaims.
The transition from deterministic names is handled with a special case for that
recovery code path: a ResourceClaim with no annotation and a name that follows
the Kubernetes <= 1.27 naming pattern is assumed to be generated for that pod
claim and gets added to the pod status.
There's no immediate need for it, but just in case that it may become relevant,
the name of the generated ResourceClaim may also be left unset to record that
no claim was needed. Components processing such a pod can skip whatever they
normally would do for the claim. To ensure that they do and also cover other
cases properly ("no known field is set", "must check ownership"),
resourceclaim.Name gets extended.
- Add SidecarContaienrs feature gate
- Add ContainerRestartPolicy type
- Add RestartPolicy field to the Container
- Drop RestartPolicy field if the feature is disabled
- Add validation for the SidecarContainers
- Allow restartable init containaers to have a startup probe
Based on https://groups.google.com/g/kubernetes-sig-storage/c/h5751_B5LQM, the
consensus was to start the deprecation in v1.28.
This commit start the deprecation process of RBD plugin from in-tree
drivers.
ACTION REQUIRED:
RBD volume plugin ( `kubernetes.io/rbd`) has been deprecated in this release
and will be removed in a subsequent release. Alternative is to use RBD CSI driver
(https://github.com/ceph/ceph-csi/) in your Kubernetes Cluster.
Signed-off-by: Humble Chirammal <humble.devassy@gmail.com>
Thes plugins are deprecated in earlier version of Kubernetes, however
the PVspec was not validated and provided enough warning that, these
are deprecated plugins. This commit add the warning and unit tests
for the same.
Signed-off-by: Humble Chirammal <humble.devassy@gmail.com>
Volume names are validated to be unique and always have been. The cited
issues are all about apply getting messed up, not the aspiserver
allowing dups.
```
$ k create -f /tmp/bad.yaml
The Deployment "bad-volumes-test" is invalid: spec.template.spec.volumes[1].name: Duplicate value: "config"
$ k apply --server-side -f /tmp/bad.yaml
Error from server: failed to create typed patch object (default/bad-volumes-test; apps/v1, Kind=Deployment): .spec.template.spec.volumes: duplicate entries for key [name="config"]
$ k apply -f /tmp/bad.yaml -o json | jq '.spec.template.spec.volumes'
The Deployment "bad-volumes-test" is invalid: spec.template.spec.volumes[1].name: Duplicate value: "config"
```
This touches cases where FromInt() is used on numeric constants, or
values which are already int32s, or int variables which are defined
close by and can be changed to int32s with little impact.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
This behavior is surprising to some users (see kubectl issues #1110 and #1385), who expect that an unlimited container will result in an unlimited pod, but that is not how PodLimits() works, as it ignores any containers that do not specify limits when calculating the pod limits.
This commit adds unit tests that confirm this behavior.
