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

Merge pull request #7756 from aojea/dns_sli 

update DNS programming latency SLI
This commit is contained in:
Kubernetes Prow Robot 2024-03-14 13:23:48 -07:00 committed by GitHub
parent 31399e5bb1 9e43c29c59
commit e9f78a322a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
sig-scalability/slos/dns_programming_latency.md
View File

@ -15,8 +15,10 @@ from all of them.
DNS will start resolving service name to its newly started backends. 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 - 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. 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. 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 ### Other notes
- We are consciously focusing on in-cluster DNS for the purpose of this SLI, - We are consciously focusing on in-cluster DNS for the purpose of this SLI,
@ -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 in 99% of programmers (e.g. iptables). That requires tracking metrics on
per-change base (which we can't do efficiently). 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 available in the service's A/AAAA record(s)
should be statisitically consistent for the first Pod and the last Pod.
### How to measure the SLI. ### How to measure the SLI.
There [network programming latency](./network_programming_latency.md) is There [network programming latency](./network_programming_latency.md) is
formulated in almost exactly the same way. As a result, the methodology for formulated in almost exactly the same way. As a result, the methodology for