kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Make Markdown and editorial tweaks

pull/36763/head
Tim Bannister 2022-09-15 17:53:11 +01:00 committed by GitHub
parent 6a20e61938
commit be474ec866
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
content/en/blog/_posts/2022-09-15-sig-apps-GA-1.25/index.md
View File

@ -1,13 +1,13 @@
--- ---
layout: blog layout: blog
title: "sig-apps features graduating to stable in 1.25" title: "SIG Apps Features Graduating to Stable in Kubernetes 1.25"
date: 2022-09-15 date: 2022-09-15
slug: "sig-apps features graduating to stable in 1.25" slug: "sig-apps-features-stable-1-25"
--- ---
**Authors:** Ravi Gudimetla (Apple), Filip Křepinský (Red Hat), Maciej Szulik (Red Hat) **Authors:** Ravi Gudimetla (Apple), Filip Křepinský (Red Hat), Maciej Szulik (Red Hat)
This blog describes the two features namely `minReadySeconds` for StatefulSets and `maxSurge` for DaemonSets that sig-apps is happy to graduate to stable in 1.25. This blog describes the two features namely `minReadySeconds` for StatefulSets and `maxSurge` for DaemonSets that SIG Apps is happy to graduate to stable in Kubernetes 1.25.
Specifying `minReadySeconds` slows down a rollout of a StatefulSet, when using a `RollingUpdate` value in `.spec.updateStrategy` field, by waiting for each pod for a desired time. Specifying `minReadySeconds` slows down a rollout of a StatefulSet, when using a `RollingUpdate` value in `.spec.updateStrategy` field, by waiting for each pod for a desired time.
This time can be used for initializing the pod (e.g. warming up the cache) or as a delay before acknowledging the pod. This time can be used for initializing the pod (e.g. warming up the cache) or as a delay before acknowledging the pod.
@ -15,29 +15,29 @@ This time can be used for initializing the pod (e.g. warming up the cache) or as
`maxSurge` allows a DaemonSet workload to run multiple instances of the same pod on a node during a rollout when using a `RollingUpdate` value in `.spec.updateStrategy` field. `maxSurge` allows a DaemonSet workload to run multiple instances of the same pod on a node during a rollout when using a `RollingUpdate` value in `.spec.updateStrategy` field.
This helps to minimize the downtime of the DaemonSet for consumers. This helps to minimize the downtime of the DaemonSet for consumers.
These features are already available in a Deployment and other workloads. This graduation helps to align this functionality across the workloads. These features were already available in a Deployment and other workloads. This graduation helps to align this functionality across the workloads.
## What problems do these features solve? ## What problems do these features solve?
### MinReadySeconds for StatefulSets ### minReadySeconds for StatefulSets {#solved-problem-statefulset-minreadyseconds}
`minReadySeconds` ensures that the StatefulSet workload is `Ready` for the given number of seconds before reporting the `minReadySeconds` ensures that the StatefulSet workload is `Ready` for the given number of seconds before reporting the
pod as `Available`. The notion of being `Ready` and `Available` is quite important for workloads. For example, some workloads, like Prometheus with multiple instances of Alertmanager, should be considered `Available` only when the Alertmanager's state transfer is complete. `minReadySeconds` also helps when using loadbalancers with cloud providers. Since the pod should be `Ready` for the given number of seconds, it provides buffer time to prevent killing pods in rotation before new pods show up. pod as `Available`. The notion of being `Ready` and `Available` is quite important for workloads. For example, some workloads, like Prometheus with multiple instances of Alertmanager, should be considered `Available` only when the Alertmanager's state transfer is complete. `minReadySeconds` also helps when using loadbalancers with cloud providers. Since the pod should be `Ready` for the given number of seconds, it provides buffer time to prevent killing pods in rotation before new pods show up.
### MaxSurge for DaemonSets ### maxSurge for DaemonSets {#how-use-daemonset-maxsurge}
Kubernetes system-level components like CNI, CSI are typically run as DaemonSets. These components can have impact on the availability of the workloads if those DaemonSets go down momentarily during the upgrades. The feature allows DaemonSet pods to temporarily increase their number, thereby ensuring zero-downtime for the DaemonSets. Kubernetes system-level components like CNI, CSI are typically run as DaemonSets. These components can have impact on the availability of the workloads if those DaemonSets go down momentarily during the upgrades. The feature allows DaemonSet pods to temporarily increase their number, thereby ensuring zero-downtime for the DaemonSets.
Please note that the usage of `HostPort` in conjunction with `MaxSurge` in DaemonSets is not allowed as DaemonSet pods are tied to a single node and two active pods cannot share the same port on the same node. Please note that the usage of `hostPort` in conjunction with `maxSurge` in DaemonSets is not allowed as DaemonSet pods are tied to a single node and two active pods cannot share the same port on the same node.
## How does it work? ## How does it work?
### MinReadySeconds for StatefulSets ### minReadySeconds for StatefulSets {#how-does-statefulset-minreadyseconds-work}
The StatefulSet controller watches for the StatefulSet pods and counts how long a particular pod has been in the `Running` state, if this value is greater than or equal to the time specified in `.spec.minReadySeconds` field of the StatefulSet, the StatefulSet controller updates the `AvailableReplicas` field in the StatefulSet's status. The StatefulSet controller watches for the StatefulSet pods and counts how long a particular pod has been in the `Running` state, if this value is greater than or equal to the time specified in `.spec.minReadySeconds` field of the StatefulSet, the StatefulSet controller updates the `AvailableReplicas` field in the StatefulSet's status.
### MaxSurge for DaemonSets ### maxSurge for DaemonSets {#how-does-daemonset-maxsurge-work}
The DaemonSet controller creates the additional pods (above the desired number resulting from DaemonSet spec) based on the value given in `.spec.strategy.rollingUpdate.maxSurge`. The additional pods would run on the same node where the old DaemonSet pod is running till the old pod gets killed. The DaemonSet controller creates the additional pods (above the desired number resulting from DaemonSet spec) based on the value given in `.spec.strategy.rollingUpdate.maxSurge`. The additional pods would run on the same node where the old DaemonSet pod is running till the old pod gets killed.
@ -47,7 +47,7 @@ The DaemonSet controller creates the additional pods (above the desired number r
## How do I use it? ## How do I use it?
### MinReadySeconds for StatefulSets ### minReadySeconds for StatefulSets {#how-use-statefulset-minreadyseconds}
Specify a value for `minReadySeconds` for any StatefulSet and check if pods are available or not by inspecting Specify a value for `minReadySeconds` for any StatefulSet and check if pods are available or not by inspecting
`AvailableReplicas` field using: `AvailableReplicas` field using:
@ -56,7 +56,7 @@ Specify a value for `minReadySeconds` for any StatefulSet and check if pods are
Please note that the default value of `minReadySeconds` is 0. Please note that the default value of `minReadySeconds` is 0.
### MaxSurge for DaemonSets ### maxSurge for DaemonSets {#how-use-daemonset-maxsurge}
Specify a value for `.spec.updateStrategy.rollingUpdate.maxSurge` and set `.spec.updateStrategy.rollingUpdate.maxUnavailable` to `0`. Specify a value for `.spec.updateStrategy.rollingUpdate.maxSurge` and set `.spec.updateStrategy.rollingUpdate.maxUnavailable` to `0`.
@ -69,16 +69,18 @@ kubectl get pods -w
## How can I learn more? ## How can I learn more?
### MinReadySeconds for StatefulSets ### minReadySeconds for StatefulSets {#learn-more-statefulset-minreadyseconds}
- Documentation: https://k8s.io/docs/concepts/workloads/controllers/statefulset/#minimum-ready-seconds
- KEP: https://github.com/kubernetes/enhancements/issues/2599 - KEP: https://github.com/kubernetes/enhancements/issues/2599
- API Changes: https://github.com/kubernetes/kubernetes/pull/100842 - API Changes: https://github.com/kubernetes/kubernetes/pull/100842
### MaxSurge for DaemonSets ### maxSurge for DaemonSets {#learn-more-daemonset-maxsurge}
- Documentation: https://k8s.io/docs/tasks/manage-daemon/update-daemon-set/
- KEP: https://github.com/kubernetes/enhancements/issues/1591 - KEP: https://github.com/kubernetes/enhancements/issues/1591
- API Changes: https://github.com/kubernetes/kubernetes/pull/96375 - API Changes: https://github.com/kubernetes/kubernetes/pull/96375
## How do I get involved? ## How do I get involved?
Please reach out to us on [#sig-apps](https://kubernetes.slack.com/archives/C18NZM5K9) channel on slack, sig-apps mailing list-kubernetes-sig-apps@googlegroups.com Please reach out to us on [#sig-apps](https://kubernetes.slack.com/archives/C18NZM5K9) channel on Slack, or through the SIG Apps mailing list [kubernetes-sig-apps@googlegroups.com](https://groups.google.com/g/kubernetes-sig-apps).