24 ‐ POD Design - CloudScope/DevOpsWithCloudScope GitHub Wiki

In Kubernetes, probes are a critical mechanism to monitor and ensure the health and readiness of containers running inside Pods. Kubernetes provides three types of probes to check the health of containers: Liveness, Readiness, and Startup probes. These probes enable Kubernetes to determine when to restart a container, when it can begin accepting traffic, and when to avoid routing traffic to it.

1. Liveness Probe

• Purpose: Determines whether a container is still running or "alive."
• When it's used: If the liveness probe fails, Kubernetes will automatically restart the container.
• Example Use Case: Detect if an application inside a container is stuck in an infinite loop or deadlock and needs to be restarted.

Probe Types:

• HTTP: Sends an HTTP GET request to the container. If the response code is between 200 and 399, the container is considered alive.
• TCP Socket: Tries to open a TCP connection to the container's IP on a specified port. If the connection is successful, the container is considered alive.
• Exec: Executes a command inside the container. If the command exits with a status code of 0, the container is considered alive.

Example YAML:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3

2. Readiness Probe

• Purpose: Determines if a container is ready to handle requests.
• When it's used: Kubernetes uses the readiness probe to decide when to send traffic to a container. If the probe fails, the container will not receive traffic from the Service until the probe succeeds again.
• Example Use Case: Wait for a web server to fully initialize before sending it traffic.

Probe Types:

• Same as Liveness Probe (HTTP, TCP Socket, Exec).

Example YAML:

readinessProbe:
  httpGet:
    path: /readiness
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

3. Startup Probe

• Purpose: Helps to determine if an application has successfully started. If a startup probe is configured, Kubernetes will use it to check the application startup. If it fails, Kubernetes will kill the container and restart it.
• When it's used: It is useful for applications that take a long time to start up. Without this probe, Kubernetes might prematurely kill and restart the container before it has a chance to finish starting up.

Probe Types:

• Same as Liveness Probe (HTTP, TCP Socket, Exec).

Example YAML:

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Key Configuration Parameters for Probes

• initialDelaySeconds: The number of seconds to wait before the probe is initiated after the container starts. Useful for containers that need some time before they're ready or alive.
• periodSeconds: How often the probe is performed.
• timeoutSeconds: How long to wait for a probe response before considering it a failure.
• failureThreshold: Number of consecutive failures required for the probe to be considered failed.
• successThreshold: Number of consecutive successes required for the probe to be considered successful.

Summary of Probe Differences

Probe Type	Purpose	Action if Failed
Liveness	Check if the container is still alive.	Restart the container.
Readiness	Check if the container is ready to serve traffic.	Stop sending traffic to the container.
Startup	Check if the container has started properly.	Only used during startup, prevent unnecessary restarts.

Additional Considerations:

• Avoid Overlapping Probes: When you set both liveness and readiness probes, be careful not to configure them to overlap too much in functionality. If both probes are configured the same, it could lead to unnecessary restarts.
• Minimal Probe Failures: Setting appropriate failureThreshold and initialDelaySeconds helps in avoiding unnecessary restarts, especially for applications that have a longer startup or are temporarily unavailable.
• Combined Probes: Sometimes, a combination of readiness and liveness probes might be useful for ensuring an application isn't prematurely restarted and is only restarted once it's actually unhealthy.

Practical Example of a Pod with All Three Probes

apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
    - name: myapp-container
      image: myapp-image
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 3
        periodSeconds: 3
      readinessProbe:
        httpGet:
          path: /readiness
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 5
      startupProbe:
        httpGet:
          path: /startup
          port: 8080
        initialDelaySeconds: 10
        periodSeconds: 5

In Kubernetes, labels, selectors, and annotations are key concepts used to organize and manage resources in a cluster. They serve different purposes but are essential for efficient management, querying, and interaction with resources.

1. Labels

Labels are key-value pairs that are attached to Kubernetes resources (like Pods, Services, Deployments, etc.). They are primarily used for grouping and selecting resources.

• Purpose: Labels allow you to organize resources and select them for specific purposes, such as grouping or identifying related resources.
• Use Case: You can use labels to select a group of Pods that share a common characteristic (e.g., version, environment).

Syntax: A label consists of a key and a value, separated by an equals sign. For example, app=nginx or tier=frontend.

Example YAML with Labels:

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    app: myapp
    environment: production
spec:
  containers:
    - name: myapp-container
      image: myapp-image

2. Selectors

Selectors are used to filter and select resources based on their labels. Kubernetes uses selectors to identify groups of resources that match certain criteria. Selectors are widely used in Services, ReplicaSets, Deployments, and other controllers to identify the Pods or resources that belong to them.

• Purpose: Selectors are primarily used to find a set of resources (e.g., Pods) that match a particular label or a set of labels.
• Use Case: Services use label selectors to route traffic to the appropriate set of Pods, ensuring that only the Pods matching a certain label are exposed.

There are two types of selectors:

1. Equality-based selectors: Match based on a key-value pair (e.g., key=value).
2. Set-based selectors: Match based on a set of values for a key (e.g., key in (value1, value2)).

Example of Label Selector in a Service:

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

In this example, the Service will select all Pods with the label app=myapp.

Example of Set-based Label Selector:

selector:
  app in (frontend, backend)

This selects Pods that have the app label with values frontend or backend.

3. Annotations

Annotations are also key-value pairs, but they serve a different purpose than labels. While labels are used for selection and grouping of resources, annotations are used to store metadata and other non-identifying information about resources.

• Purpose: Annotations are used to store arbitrary metadata, like build numbers, URLs, configuration details, and other information that doesn't affect the operation or grouping of resources.
• Use Case: Annotations are useful for storing details such as the version of the resource, deployment information, and other debugging or operational data that you don't need to query directly.

Annotations are typically not used for selecting or grouping resources, unlike labels.

Example YAML with Annotations:

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  annotations:
    deployment.kubernetes.io/revision: "1"
    build: "v1.2.3"
spec:
  containers:
    - name: myapp-container
      image: myapp-image

Key Differences Between Labels and Annotations

Feature	Labels	Annotations
Purpose	Used for grouping, selection, and organization	Used for storing arbitrary metadata
Size Limit	Limited to 63 characters per key, 253 characters per value	No size limits; can be much larger
Querying	Can be used for selectors to filter and select resources	Not used for selectors or filtering
Indexing	Indexed by Kubernetes for efficient querying	Not indexed (less efficient for querying)
Use Case	Service discovery, filtering resources for deployments, scaling, etc.	Storing deployment details, configuration information, etc.

Practical Examples

• Labeling Pods for Deployment: You can label Pods and use a Deployment to manage them based on those labels.

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: myapp-deployment
  spec:
    replicas: 3
    selector:
      matchLabels:
        app: myapp
    template:
      metadata:
        labels:
          app: myapp
      spec:
        containers:
        - name: myapp-container
          image: myapp-image
  

• Using Annotations for Metadata:

  apiVersion: v1
  kind: Pod
  metadata:
    name: myapp
    annotations:
      description: "This pod runs the frontend of the application."
      author: "dev-team"
  

---

---

Summary

• Labels are used for organizing, grouping, and selecting resources, making them fundamental for managing Kubernetes resources in an efficient and scalable way.
• Selectors allow you to query and filter resources based on label values.
• Annotations are used to store non-identifying metadata and other details that are not intended for selection or grouping.