@@ -331,7 +331,7 @@ spec:
331
331
` ` `
332
332
333
333
A Pod with Always restart policy with an init container that only execute once. If the init
334
- container fails, the Pod fails. This allows the Pod to fail if the initialiaztion failed,
334
+ container fails, the Pod fails. This allows the Pod to fail if the initialization failed,
335
335
but also keep running once the initialization succeeds:
336
336
337
337
` ` ` yaml
@@ -485,7 +485,7 @@ spec:
485
485
- conditionType: "www.example.com/feature-1"
486
486
status:
487
487
conditions:
488
- - type: Ready # a built in PodCondition
488
+ - type: Ready # a built- in PodCondition
489
489
status: "False"
490
490
lastProbeTime: null
491
491
lastTransitionTime: 2018-01-01T00:00:00Z
@@ -683,7 +683,7 @@ processing its startup data, you might prefer a readiness probe.
683
683
{{< note >}}
684
684
If you want to be able to drain requests when the Pod is deleted, you do not
685
685
necessarily need a readiness probe; when the Pod is deleted, the corresponding endpoint
686
- in the `EndppointSlice ` will update its [conditions](/docs/concepts/services-networking/endpoint-slices/#conditions):
686
+ in the `EndpointSlice ` will update its [conditions](/docs/concepts/services-networking/endpoint-slices/#conditions):
687
687
the endpoint `ready` condition will be set to `false`, so load balancers
688
688
will not use the Pod for regular traffic. See [Pod termination](#pod-termination)
689
689
for more information about how the kubelet handles Pod deletion.
0 commit comments