mirror of https://github.com/k3s-io/k3s
e9bd805888
Automatic merge from submit-queue
Move init-container feature from alpha to beta.
```release-note
Moved init-container feature from alpha to beta.
In 1.3, an init container is specified with this annotation key
on the pod or pod template: `pods.alpha.kubernetes.io/init-containers`.
In 1.4, either that key or this key: pods.beta.kubernetes.io/init-containers`,
can be used.
When you GET an object, you will see both annotation keys with the same values.
You can safely roll back from 1.4 to 1.3, and things with init-containers
will still work (pods, deployments, etc).
If you are running 1.3, only use the alpha annotation, or it may be lost when
rolling forward.
The status has moved from annotation key
`pods.beta.kubernetes.io/init-container-statuses` to
`pods.beta.kubernetes.io/init-container-statuses`.
Any code that inspects this annotation should be changed to use the new key.
State of Initialization will continue to be reported in both pods.alpha.kubernetes.io/initialized
and in `podStatus.conditions.{status: "True", type: Initialized}`
```
Mini-design for this change:
Goals:
1. A user can create an object with the beta annotation
on 1.4, and it works. The fact that the annotation has beta
in it communicates to the user that the feature is beta,
and so the user should have confidence in using it. Preferably,
when the user gets the annotation back, he see the beta
annotation.
1) If someone had an existing alpha object in their apiserver,
such as a RS with a pod template with an init-containers
annotation on it, it should continue to work (init containers
run) when stack upgraded to 1.4.
2) If someone is using a chart or blog post that has alpha
annotation on it and they create it on a 1.4 cluster, it should
work.
3) If someone had something with an init container in 1.4
and they roll back stack to 1.3, it should not silently stop
working (init containers don't run anymore).
To meet all these, we mirror an absent beta label from the alpha
key and vice versa. If they are out of sync, we use the alpha
one. We do this in conversion since there was already logic there.
In 1.3 code, all annotations are preserved across a round trip
(v1 -> api -> v1), and the alpha annotation turns into the internal
field that kubelet uses.
In 1.4 code, the alpha annotation is always preserved across
a round trip, and a beta annotation is always set equal to
the alpha one, after a round trip.
Currently, the kubelet always sees the object after a round trip
when it GETs it. But, we don't want to rely on that behavior,
since it will break when fastpath is implemented.
So, we rely on this:
all objects either are created with an alpha annotation (1.3 or 1.4
code) or are created with a beta annotation under 1.4. In the later
case, they are round tripped at creation time, and so get both
annotations. So all subsequent GETs see both labels.
|
||
|---|---|---|
| .. | ||
| annotations | ||
| endpoints | ||
| errors | ||
| install | ||
| meta | ||
| pod | ||
| resource | ||
| rest | ||
| service | ||
| testapi | ||
| testing | ||
| unversioned | ||
| util | ||
| v1 | ||
| validation | ||
| OWNERS | ||
| context.go | ||
| context_test.go | ||
| conversion.go | ||
| conversion_test.go | ||
| copy_test.go | ||
| deep_copy_test.go | ||
| defaults.go | ||
| doc.go | ||
| field_constants.go | ||
| generate.go | ||
| generate_test.go | ||
| helpers.go | ||
| helpers_test.go | ||
| mapper.go | ||
| meta.go | ||
| meta_test.go | ||
| node_example.json | ||
| ref.go | ||
| ref_test.go | ||
| register.go | ||
| replication_controller_example.json | ||
| requestcontext.go | ||
| resource_helpers.go | ||
| resource_helpers_test.go | ||
| serialization_proto_test.go | ||
| serialization_test.go | ||
| types.generated.go | ||
| types.go | ||
| zz_generated.deepcopy.go | ||