Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update DNS programming latency SLI #7756

Merged
merged 3 commits into from
Mar 14, 2024
Merged

update DNS programming latency SLI #7756

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
434c37c
update DNS programming latency SLI
aojea Mar 13, 2024
f9b6920
Update sig-scalability/slos/dns_programming_latency.md
aojea Mar 13, 2024
9e43c29
Update sig-scalability/slos/dns_programming_latency.md
aojea Mar 14, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion sig-scalability/slos/dns_programming_latency.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,10 @@ from all of them.
DNS will start resolving service name to its newly started backends.
- As a user of vanilla Kubernetes, I want some guarantee how quickly in-cluster
DNS will stop resolving service name to its removed (or unhealthy) backends.
- As a user of vanilla Kubernetes, I wasn some guarantee how quickly newly
- As a user of vanilla Kubernetes, I want some guarantee how quickly newly
create services will be resolvable via in-cluster DNS.
- As a user of vanilla Kubernetes, I want some guarantee how quickly in-cluster
DNS will start resolving headless service hostnames to its newly started backends.

### Other notes
- We are consciously focusing on in-cluster DNS for the purpose of this SLI,
Expand All @@ -37,6 +39,12 @@ The reason for doing it this way is feasibility for efficiently computing that:
in 99% of programmers (e.g. iptables). That requires tracking metrics on
per-change base (which we can't do efficiently).

- The SLI for DNS publishing should remain constant independent of the number of records.
For example, in a headless service with thousands of pods the time between the pod being
assigned an IP and the time DNS makes that IP availabe in the service's A/AAAA record(s)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: available

[but it's failing presubmit]

should be statisitically consistent for the first Pod and the last Pod.


### How to measure the SLI.
There [network programming latency](./network_programming_latency.md) is
formulated in almost exactly the same way. As a result, the methodology for
Expand Down