Promote StartupProbe to beta (enabled by default). (#17164)

static/docs/reference/generated/kubernetes-api/v1.16/index.html

@@ -3914,7 +3914,7 @@ image: nginx:1.10
 <TR><TD><CODE>readinessProbe</CODE><BR /><I><a href="#probe-v1-core">Probe</a></I></TD><TD>Periodic probe of container service readiness. Container will be removed from service endpoints if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes</TD></TR>
 <TR><TD><CODE>resources</CODE><BR /><I><a href="#resourcerequirements-v1-core">ResourceRequirements</a></I></TD><TD>Compute Resources required by this container. Cannot be updated. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/</TD></TR>
 <TR><TD><CODE>securityContext</CODE><BR /><I><a href="#securitycontext-v1-core">SecurityContext</a></I></TD><TD>Security options the pod should run with. More info: https://kubernetes.io/docs/concepts/policy/security-context/ More info: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/</TD></TR>
-<TR><TD><CODE>startupProbe</CODE><BR /><I><a href="#probe-v1-core">Probe</a></I></TD><TD>StartupProbe indicates that the Pod has successfully initialized. If specified, no other probes are executed until this completes successfully. If this probe fails, the Pod will be restarted, just as if the livenessProbe failed. This can be used to provide different probe parameters at the beginning of a Pod&#39;s lifecycle, when it might take a long time to load data or warm a cache, than during steady-state operation. This cannot be updated. This is an alpha feature enabled by the StartupProbe feature flag. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes</TD></TR>
+<TR><TD><CODE>startupProbe</CODE><BR /><I><a href="#probe-v1-core">Probe</a></I></TD><TD>StartupProbe indicates that the Pod has successfully initialized. If specified, no other probes are executed until this completes successfully. If this probe fails, the Pod will be restarted, just as if the livenessProbe failed. This can be used to provide different probe parameters at the beginning of a Pod&#39;s lifecycle, when it might take a long time to load data or warm a cache, than during steady-state operation. This cannot be updated. This is an beta feature enabled by default that can be disabled using the StartupProbe feature flag. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes</TD></TR>
 <TR><TD><CODE>stdin</CODE><BR /><I>boolean</I></TD><TD>Whether this container should allocate a buffer for stdin in the container runtime. If this is not set, reads from stdin in the container will always result in EOF. Default is false.</TD></TR>
 <TR><TD><CODE>stdinOnce</CODE><BR /><I>boolean</I></TD><TD>Whether the container runtime should close the stdin channel after it has been opened by a single attach. When stdin is true the stdin stream will remain open across multiple attach sessions. If stdinOnce is set to true, stdin is opened on container start, is empty until the first client attaches to stdin, and then remains open and accepts data until the client disconnects, at which time stdin is closed and remains closed until the container is restarted. If this flag is false, a container processes that reads from stdin will never receive an EOF. Default is false</TD></TR>
 <TR><TD><CODE>terminationMessagePath</CODE><BR /><I>string</I></TD><TD>Optional: Path at which the file to which the container&#39;s termination message will be written is mounted into the container&#39;s filesystem. Message written is intended to be brief final status, such as an assertion failure message. Will be truncated by the node if greater than 4096 bytes. The total message length across all containers will be limited to 12kb. Defaults to /dev/termination-log. Cannot be updated.</TD></TR>