From 3fbca8f29691a5ca9f584d824b30404dd5117688 Mon Sep 17 00:00:00 2001 From: wojtekt Date: Thu, 23 Aug 2018 13:16:41 +0200 Subject: [PATCH] Fix secrets docs --- content/en/docs/concepts/configuration/secret.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index e2469c1c83fc6..6bcddd9361ef7 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -339,9 +339,15 @@ files. When a secret being already consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted secret is fresh on every periodic sync. -However, it is using its local ttl-based cache for getting the current value of the secret. -As a result, the total delay from the moment when the secret is updated to the moment when new keys are -projected to the pod can be as long as kubelet sync period + ttl of secrets cache in kubelet. +However, it is using its local cache for getting the current value of the secret. +The type of the cache is configurable (`ConfigMapAndSecretChangeDetectionStrategy` field in +[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/release-1.12/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go)) +and can be either propagated via watch (default), ttl-based or simply redirecting +all requests to directly kube-apiserver. +As a result, the total delay from the moment when the secret is updated to the moment +when new keys are projected to the pod can be as long as kubelet sync period + cache +propagation delay, where cache propagation delay depends on the chosen cache type +(it equals to watch propagation delay, ttl of cache or zero corespondingly). {{< note >}} **Note:** A container using a Secret as a