API Deprecations

Question 1

What does the Kubernetes API deprecation policy explain?

Answer 1

It explains why multiple API versions may exist at the same time and when older API versions can be deprecated or removed.

Question 2

Why might a Kubernetes API group support multiple versions at once?

Answer 2

It supports multiple versions so older manifests keep working while users gradually migrate to newer API versions.

Question 3

What is the rule for removing an API element such as a resource or field from an API group?

Answer 3

API elements may only be removed by incrementing the API version rather than being removed from the same version.

Question 4

Why must Kubernetes sometimes support both an older and a newer API version at the same time?

Answer 4

It must support both versions so users do not have to rewrite all manifests immediately when a new API version is introduced.

Question 5

What does it mean that API objects must round trip between versions without information loss?

Answer 5

It means an object converted from one version to another and back again should remain logically equivalent unless the whole resource does not exist in one version.

Question 6

How are alpha API versions treated by the deprecation policy?

Answer 6

Alpha versions are experimental and do not have to be supported across future releases so they may be removed quickly.

Question 7

How are beta API versions treated by the deprecation policy?

Answer 7

Beta versions must be supported for at least three releases or nine months whichever is longer after deprecation.

Question 8

How are GA stable API versions treated by the deprecation policy?

Answer 8

GA versions must be supported for at least three releases or twelve months whichever is longer after deprecation.

Question 9

What happens when an API version is deprecated but not yet removed?

Answer 9

It still works for a period of time but users should migrate and Kubernetes may show deprecation warnings.

Question 10

What is the preferred API version for a group?

Answer 10

The preferred version is the default version kubectl and API discovery tend to use when retrieving resource information.

Question 11

What is the storage version for a group?

Answer 11

The storage version is the version used to persist objects in etcd even if the object was created with another supported version.

Question 12

When can the preferred version or storage version move to a newer API version?

Answer 12

They cannot move until there has been at least one release that supports both the new version and the previous version together.

Question 13

Can a less stable API version deprecate a more stable API version?

Answer 13

No a less stable version such as alpha cannot deprecate a more stable version such as GA.

Question 14

In the lecture example could v2alpha1 deprecate v1 GA?

Answer 14

No because a GA version can only be deprecated by a new version that is at least equally stable.

Question 15

Why are release notes important when API versions are removed?

Answer 15

Release notes tell users which old API versions are being removed and which newer versions they must migrate to.

Question 16

What is kubectl convert used for?

Answer 16

kubectl convert is used to rewrite older manifest files into a newer supported API version.

Question 17

Why is kubectl convert useful during cluster upgrades?

Answer 17

It helps update old manifests when deprecated API versions are removed from newer Kubernetes releases.

Question 18

What important detail about kubectl convert is mentioned in the lecture?

Answer 18

kubectl convert is a separate plugin and may need to be installed before you can use it.