PodProbeMarker

    Kubernetes provides three Pod lifecycle management:

    • Liveness Probe Used to determine the health status of the container. If the probe fails, the kubelet will restart the container.
    • Startup Probe Used to know when a container application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds.

    So the Probe capabilities provided in Kubernetes have defined specific semantics and related behaviors. In addition, there is actually a need to customize Probe semantics and related behaviors, such as:

    • GameServer defines Idle Probe to determine whether the Pod currently has a game match, if not, from the perspective of cost optimization, the Pod can be scaled down.
    • K8S Operator defines the main-secondary probe to determine the role of the current Pod (main or secondary). When upgrading, the secondary can be upgraded first, so as to achieve the behavior of selecting the main only once during the upgrade process, reducing the service interruption time during the upgrade process.

    PodProbeMarker feature is turned off by default, if you want to turn it on set feature-gate PodProbeMarkerGate.

    • spec.selector: Select matching Pods based on Labels, both MatchLabels and MatchExpressions are supported. For details, please refer to: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels. Once specified, selector cannot be changed for a PodProbeMarker.
    • spec.probes
      • containerName: The container that executes the probe
      • probe: The API definition related to probe is consistent with the native K8S probe (currently only Exec is supported). For details, please refer to:
      • markerPolicy: According to the Probe execution result (Succeeded or Failed), patch specific Labels and Annotations to the Pod.
        • state: probe result, Succeeded or Failed
        • labels: If the result is satisfied, patch labels to the Pod
        • annotations: If the result is satisfied, patch annotations to the Pod

    Note: If only one Marker Policy is defined, for example: only define State=Succeeded, Patch Labels[healthy]\=’true’. When the probe execution success, kruise will patch labels[healthy]\=’true’ to pod. And when the probe execution fails, Label[healthy] will be deleted.

    This method can be used in combination with Kubernetes Readiness Gate to flexibly control whether the Pod is Ready.

    If the user defines the MarkerPolicy, OpenKruise will patch the specific Metadata to the Pod, as follows:

    Through the pod event, you can view the historical probe execution results, as follows: