feat: expose rollout controls and the status endpoint in the apisix chart - #1007
Open
4refael wants to merge 1 commit into
Open
feat: expose rollout controls and the status endpoint in the apisix chart#10074refael wants to merge 1 commit into
4refael wants to merge 1 commit into
Conversation
…hart Signed-off-by: refael iliaguyev <4refael@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
During a rolling update in etcd mode, new pods receive traffic before they are ready. For a short time they answer 404. The cause: the readiness probe is only a TCP check on the proxy port. The pod becomes Ready when nginx starts to listen. At that moment, the workers have not loaded the routes from etcd yet.
APISIX already has a correct readiness endpoint:
/status/ready. It returns 200 only after every worker has loaded the configuration. It works in etcd mode too, since APISIX 3.13.0 (apache/apisix#12200). But the chart enables this endpoint only forrole_traditional+config_provider: yaml.There is a second problem, at shutdown. The chart lets you configure a graceful drain (
apisix.nginx.workerShutdownTimeout), but it does not let you configureterminationGracePeriodSeconds. So Kubernetes always kills a stopping pod after 30 seconds, even when the drain timeout is longer.Changes
apisix.status.enabled: enables the status endpoint in every deployment mode. When it is on, the default readiness probe useshttpGet /status/readyinstead of the TCP check.terminationGracePeriodSeconds,minReadySeconds,progressDeadlineSeconds, andlivenessProbe/readinessProbeoverrides.Related work
Closes #951. Issue #951 and PR #952 ask for a configurable
livenessProbe. This PR includes one, as a full-map override value instead of a fixed-fields toggle, so users control every probe field. The new values live at the top level of values.yaml, next to the existingupdateStrategy.No change for existing users
All defaults keep the current behavior. A render with default values is identical to master, except that
progressDeadlineSeconds: 600andterminationGracePeriodSeconds: 30are now written explicitly — both are the Kubernetes defaults. Note:terminationGracePeriodSecondsis part of the pod template, so the first upgrade to this chart version restarts the APISIX pods one time. I verified the renders for the etcd, traditional yaml, DaemonSet, and control_plane modes.ct lintpasses.