Merge branch 'dev-1.16' into merged-master-dev-1.16

content/en/docs/tasks/configure-pod-container/configure-gmsa.md

@@ -133,7 +133,7 @@ roleRef:
 ```
 
 ## Configure GMSA credential spec reference in pod spec
-In the alpha stage of the feature, the annotation `pod.alpha.windows.kubernetes.io/gmsa-credential-spec-name` is used to specify references to desired GMSA credential spec custom resources in pod specs. This configures all containers in the pod spec to use the specified GMSA. A sample pod spec with the annotation populated to refer to `gmsa-WebApp1`:
+In the alpha stage of the feature, the pod spec field `securityContext.windowsOptions.gmsaCredentialSpecName` is used to specify references to desired GMSA credential spec custom resources in pod specs. This configures all containers in the pod spec to use the specified GMSA. A sample pod spec with the annotation populated to refer to `gmsa-WebApp1`:
 
 ```
 apiVersion: apps/v1beta1
@@ -152,9 +152,10 @@ spec:
     metadata:
       labels:
         run: with-creds
-      annotations:
-        pod.alpha.windows.kubernetes.io/gmsa-credential-spec-name: gmsa-WebApp1  # This must be the name of the cred spec you created
     spec:
+      securityContext:
+        windowsOptions:
+          gmsaCredentialSpecName: gmsa-webapp1
       containers:
       - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
         imagePullPolicy: Always
@@ -163,7 +164,7 @@ spec:
         beta.kubernetes.io/os: windows
 ```
 
-Individual containers in a pod spec can also specify the desired GMSA credspec using annotation `<containerName>.container.alpha.windows.kubernetes.io/gmsa-credential-spec`. For example:
+Individual containers in a pod spec can also specify the desired GMSA credspec using a per-container `securityContext.windowsOptions.gmsaCredentialSpecName` field. For example:
 
 ```
 apiVersion: apps/v1beta1
@@ -182,13 +183,14 @@ spec:
     metadata:
       labels:
         run: with-creds
-      annotations:
-        iis.container.alpha.windows.kubernetes.io/gmsa-credential-spec-name: gmsa-WebApp1  # This must be the name of the cred spec you created
     spec:
       containers:
       - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
         imagePullPolicy: Always
         name: iis
+        securityContext:
+          windowsOptions:
+            gmsaCredentialSpecName: gmsa-Webapp1
       nodeSelector:
         beta.kubernetes.io/os: windows
 ```

content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md

@@ -19,6 +19,12 @@ accepting traffic. A Pod is considered ready when all of its Containers are read
 One use of this signal is to control which Pods are used as backends for Services.
 When a Pod is not ready, it is removed from Service load balancers.
 
+The kubelet uses startup probes to know when a Container application has started.
+If such a probe is configured, it disables liveness and readiness checks until
+it succeeds, making sure those probes don't interfere with the application startup.
+This can be used to adopt liveness checks on slow starting containers, avoiding them
+getting killed by the kubelet before they are up and running.
+
 {{% /capture %}}
 
 {{% capture prerequisites %}}
@@ -231,6 +237,46 @@ livenessProbe:
     port: liveness-port
 ```
 
+## Protect slow starting containers with startup probes {#define-startup-probes}
+
+Sometimes, you have to deal with legacy applications that might require
+an additional startup time on their first initialization.
+In such cases, it can be tricky to setup liveness probe parameters without
+compromising the fast response to deadlocks that motivated such a probe.
+The trick is to setup a startup probe with the same command, HTTP or TCP
+check, with a `failureThreshold * periodSeconds` long enough to cover the
+worse case startup time.
+
+So, the previous example would become:
+
+```yaml
+ports:
+- name: liveness-port
+  containerPort: 8080
+  hostPort: 8080
+
+livenessProbe:
+  httpGet:
+    path: /healthz
+    port: liveness-port
+  failureThreshold: 1
+  periodSeconds: 10
+
+startupProbe:
+  httpGet:
+    path: /healthz
+    port: liveness-port
+  failureThreshold: 30
+  periodSeconds: 10
+```
+
+Thanks to the startup probe, the application will have a maximum of 5 minutes
+(30 * 10 = 300s) to finish its startup.
+Once the startup probe has succeeded once, the liveness probe takes over to
+provide a fast response to container deadlocks.
+If the startup probe never succeeds, the container is killed after 300s and
+subject to the pod's `restartPolicy`.
+
 ## Define readiness probes
 
 Sometimes, applications are temporarily unable to serve traffic.

content/en/docs/tasks/configure-pod-container/quality-service-pod.md

@@ -261,9 +261,10 @@ kubectl delete namespace qos-example
 * [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
 
 * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
+
+* [Control Topology Management policies on a node](/docs/tasks/administer-cluster/topology-manager/)
 {{% /capture %}}
 
 
 
 
-