From 434c37c39cca973d7e509ec3a76c966c1e3837f1 Mon Sep 17 00:00:00 2001 From: Antonio Ojea Date: Wed, 13 Mar 2024 14:19:20 +0000 Subject: [PATCH 1/3] update DNS programming latency SLI --- sig-scalability/slos/dns_programming_latency.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sig-scalability/slos/dns_programming_latency.md b/sig-scalability/slos/dns_programming_latency.md index d2844af33..c8f59948e 100644 --- a/sig-scalability/slos/dns_programming_latency.md +++ b/sig-scalability/slos/dns_programming_latency.md @@ -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, @@ -37,6 +39,10 @@ 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 is expected to remain constant independently of the number of records, per +example, in a headless service with thousands of pods the SLI for the first and the +last Pod should not exhibit a statistically significant difference. + ### 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 From f9b6920a0ab2975852d36febd3ace26b77abc60f Mon Sep 17 00:00:00 2001 From: Antonio Ojea Date: Thu, 14 Mar 2024 00:11:24 +0100 Subject: [PATCH 2/3] Update sig-scalability/slos/dns_programming_latency.md Co-authored-by: Tim Hockin --- sig-scalability/slos/dns_programming_latency.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/sig-scalability/slos/dns_programming_latency.md b/sig-scalability/slos/dns_programming_latency.md index c8f59948e..57bc959b6 100644 --- a/sig-scalability/slos/dns_programming_latency.md +++ b/sig-scalability/slos/dns_programming_latency.md @@ -39,9 +39,11 @@ 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 is expected to remain constant independently of the number of records, per -example, in a headless service with thousands of pods the SLI for the first and the -last Pod should not exhibit a statistically significant difference. +- 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) +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 From 9e43c29c5992b505d3b697a5866be8e56ab6badf Mon Sep 17 00:00:00 2001 From: Antonio Ojea Date: Thu, 14 Mar 2024 18:35:13 +0100 Subject: [PATCH 3/3] Update sig-scalability/slos/dns_programming_latency.md --- sig-scalability/slos/dns_programming_latency.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sig-scalability/slos/dns_programming_latency.md b/sig-scalability/slos/dns_programming_latency.md index 57bc959b6..9e2482ab5 100644 --- a/sig-scalability/slos/dns_programming_latency.md +++ b/sig-scalability/slos/dns_programming_latency.md @@ -41,7 +41,7 @@ The reason for doing it this way is feasibility for efficiently computing that: - 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) +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.