### Startup Example with TLS Certificates

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/configuration.md

Demonstrates creating TLS certificates and then starting the function-auto-ready server with TLS enabled and a 2-minute TTL.

```bash
# Create TLS certificates (example)
mkdir -p /etc/tls/certs
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/tls/certs/tls.key \
  -out /etc/tls/certs/tls.crt

# Start server
./function-auto-ready \
  --tls-server-certs-dir /etc/tls/certs \
  --address :9443 \
  --ttl 2m
```

--------------------------------

### YAML: ClusterIP Service Example

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-service.md

An example of a ClusterIP Service, which is considered immediately ready.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
status:
  loadBalancer: {}
```

--------------------------------

### Ready Job Example (Successfully Completed)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-job.md

This example demonstrates a Kubernetes Job that is considered ready because its 'Complete' condition is set to 'True'.

```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
  namespace: default
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4
status:
  completionTime: 2024-01-15T10:35:00Z
  conditions:
  - type: Complete
    status: "True"
    lastProbeTime: 2024-01-15T10:35:00Z
    lastTransitionTime: 2024-01-15T10:35:00Z
  - type: Failed
    status: "False"
    lastProbeTime: 2024-01-15T10:35:00Z
    lastTransitionTime: 2024-01-15T10:35:00Z
  succeeded: 1
  active: 0
```

--------------------------------

### Example: Ready Pod (Running with Always restart policy)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-pod.md

This example shows a Pod that is considered ready. It is running, has the Ready condition set to True, and no container failures.

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: healthy-pod
  namespace: default
spec:
  restartPolicy: Always
  containers:
  - name: app
    image: nginx:1.19
status:
  phase: Running
  conditions:
  - type: Ready
    status: "True"
    lastProbeTime: null
    lastTransitionTime: 2024-01-15T10:30:00Z
  containerStatuses:
  - name: app
    ready: true
    state:
      running:
        startedAt: 2024-01-15T10:29:00Z
```

--------------------------------

### Example: Not Ready Pod (CrashLoopBackOff)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-pod.md

This example shows a Pod that is not ready due to a container being in the CrashLoopBackOff state.

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: failing-pod
  namespace: default
spec:
  restartPolicy: Always
  containers:
  - name: app
    image: broken:1.0
status:
  phase: Running
  conditions:
  - type: Ready
    status: "False"
  containerStatuses:
  - name: app
    ready: false
    state:
      waiting:
        reason: CrashLoopBackOff
        message: "Back-off 2m40s restarting failed container..."
```

--------------------------------

### Example CLI Initialization and Run

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/cli-type.md

Demonstrates how to initialize a CLI struct with specific configurations and call its Run method. This example shows setting debug, network, address, TLS directory, insecure mode, message size, and TTL.

```go
package main

import (
	"fmt"
	"github.com/alecthomas/kong"
)

func main() {
	cli := &CLI{
		Debug:              true,
		Network:            "tcp",
		Address:            ":9443",
		TLSCertsDir:        "/etc/tls",
		Insecure:           false,
		MaxRecvMessageSize: 4,
		TTL:                nil,
	}
	
	if err := cli.Run(); err != nil {
		fmt.Println("Server error:", err)
	}
}
```

--------------------------------

### YAML: NodePort Service Example

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-service.md

An example of a NodePort Service, which is considered immediately ready.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: default
spec:
  type: NodePort
  selector:
    app: MyApp
  ports:
  - port: 80
    targetPort: 9376
    nodePort: 30007
status:
  loadBalancer: {}
```

--------------------------------

### Example: Succeeded Pod (Job completion)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-pod.md

This example shows a Pod that has completed successfully and is therefore considered ready.

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: completed-job-pod
  namespace: default
spec:
  restartPolicy: Never
status:
  phase: Succeeded
```

--------------------------------

### Running Job Example (In Progress)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-job.md

This example illustrates a Kubernetes Job that is still in progress and not yet ready, as indicated by the absence of a 'Complete' condition with a 'True' status.

```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: long-running-job
spec:
  template:
    spec:
      containers:
      - name: worker
        image: busybox:1.28
        command: ["sh", "-c", "sleep 300"]
      restartPolicy: Never
  backoffLimit: 3
status:
  startTime: 2024-01-15T10:30:00Z
  conditions:
  - type: Complete
    status: "False"
  - type: Failed
    status: "False"
  active: 1
  succeeded: 0
```

--------------------------------

### Run Method

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/cli-type.md

Initializes and starts the function server with the configured options.

```APIDOC
## Run Method

### Description
Initializes the function server with the provided configuration and starts listening for gRPC connections.

### Method Signature
`func (c *CLI) Run() error`

### Parameters
None

### Returns
- `error`: Error if server initialization or startup fails; `nil` on success.

### Behavior
1. Creates a logger instance based on the `Debug` flag.
2. Resolves the `TTL` value (uses provided value or SDK default).
3. Initializes and starts the gRPC server with configured network, address, mTLS settings, message size limits, and the function handler.

### Configuration Details
- If `--insecure` flag is set, all TLS configuration is bypassed.
- If `TLSCertsDir` is empty and not in insecure mode, mTLS setup may fail or use defaults.
- `MaxRecvMessageSize` is converted to bytes by multiplying by 1,048,576 (1 MB).
```

--------------------------------

### Example: Ready StatefulSet

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-statefulset.md

A sample StatefulSet configuration where all replicas are ready and updated to the current revision.

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  namespace: default
spec:
  serviceName: nginx
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
        ports:
        - containerPort: 80
          name: web
status:
  observedGeneration: 1
  replicas: 3
  readyReplicas: 3
  currentReplicas: 3
  updatedReplicas: 3
  currentRevision: web-abc123def456
  updateRevision: web-abc123def456
  availableReplicas: 3
```

--------------------------------

### CLI Command-Line Usage Examples

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/cli-type.md

Illustrates various ways to run the function-auto-ready CLI with different configurations. Examples include running in insecure mode, enabling mTLS, setting debug logging, custom TTL, and adjusting message size.

```bash
# Run with default settings (insecure mode)
./function-auto-ready --insecure
```

```bash
# Run with mTLS enabled
./function-auto-ready \
  --tls-server-certs-dir=/etc/tls \
  --address=0.0.0.0:9443
```

```bash
# Run with debug logging and custom TTL
./function-auto-ready \
  -d \
  --insecure \
  --ttl=90s
```

```bash
# Run with large message size support
./function-auto-ready \
  --insecure \
  --max-recv-message-size=16
```

--------------------------------

### Example: Ready ReplicaSet

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-replicaset.md

A sample ReplicaSet configuration that meets all readiness criteria, resulting in a 'Ready: true' status.

```yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  namespace: default
  generation: 1
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
status:
  replicas: 3
  fullyLabeledReplicas: 3
  readyReplicas: 3
  availableReplicas: 3
  observedGeneration: 1
  conditions:
  - type: ReplicaSetReplicaFailure
    status: "False"
```

--------------------------------

### Ready HPA Example (ScalingActive)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-hpa.md

This example demonstrates a HorizontalPodAutoscaler that is considered ready because the 'ScalingActive' condition is true, and no failed conditions are present.

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
status:
  observedGeneration: 1
  lastScaleTime: 2024-01-15T10:30:00Z
  currentReplicas: 2
  desiredReplicas: 3
  conditions:
  - type: ScalingActive
    status: "True"
    lastTransitionTime: 2024-01-15T10:15:00Z
    reason: ValidMetricsFound
    message: "the HPA was able to successfully calculate a replica count from cpu resource"
  - type: ScalingLimited
    status: "False"
    lastTransitionTime: 2024-01-15T10:15:00Z
    reason: DesiredWithinRange
    message: "Desired count is within the acceptable range"
```

--------------------------------

### Ready HPA Example (ScalingLimited)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-hpa.md

This example shows a HorizontalPodAutoscaler that is ready because the 'ScalingLimited' condition is true, indicating it would scale but is constrained by its min/max replica settings.

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
status:
  currentReplicas: 5
  desiredReplicas: 10
  conditions:
  - type: ScalingActive
    status: "True"
  - type: ScalingLimited
    status: "True"
    reason: TooManyReplicas
    message: "the desired replica count is more than the maximum replica count"
```

--------------------------------

### Example: StatefulSet During Rolling Update

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-statefulset.md

A StatefulSet example demonstrating a rolling update in progress, where not all replicas are at the current revision.

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: nginx
  replicas: 3
status:
  observedGeneration: 2
  replicas: 3
  readyReplicas: 3
  currentReplicas: 2
  updatedReplicas: 1
  currentRevision: web-xyz789abc123
  updateRevision: web-def456ghi789
```

--------------------------------

### ExternalName Service Example

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-service.md

An example of an ExternalName Service. ExternalName services are considered immediately ready.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: default
spec:
  type: ExternalName
  externalName: my.example.com
```

--------------------------------

### Example: Ready DaemonSet

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-daemonset.md

A sample DaemonSet configuration where all status conditions indicate readiness. This includes matching desired, updated, ready, and available pod counts.

```yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluentd:v1.14
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
status:
  desiredNumberScheduled: 3
  updatedNumberScheduled: 3
  numberReady: 3
  numberAvailable: 3
  observedGeneration: 1
```

--------------------------------

### Example: DaemonSet with Pods Not Ready

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-daemonset.md

This DaemonSet example shows a scenario where not all desired pods are ready. The `numberReady` count is lower than `desiredNumberScheduled`, indicating a potential issue with pod readiness.

```yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      name: fluentd
status:
  desiredNumberScheduled: 3
  updatedNumberScheduled: 3
  numberReady: 2
  numberAvailable: 2
  observedGeneration: 1
```

--------------------------------

### Example: Replica Failure Condition

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-replicaset.md

A ReplicaSet example that is not ready due to the presence of a 'ReplicaSetReplicaFailure' condition with a status of 'True'.

```yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  generation: 1
spec:
  replicas: 3
status:
  replicas: 1
  availableReplicas: 1
  observedGeneration: 1
  conditions:
  - type: ReplicaSetReplicaFailure
    status: "True"
    reason: "FailedCreate"
    message: "Error creating pod: pod quota exceeded"
```

--------------------------------

### Example Composition Usage

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/README.md

Demonstrates how to include the function-auto-ready in a Crossplane Composition's pipeline. No specific input is required for the auto-ready step.

```yaml
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: example
spec:
  compositeTypeRef:
    apiVersion: example.crossplane.io/v1beta1
    kind: MyXR
  mode: Pipeline
  pipeline:
  - step: create-resources
    functionRef:
      name: function-go-templating
    input: ...
  
  - step: auto-ready  # Automatically detect readiness
    functionRef:
      name: function-auto-ready
    # No input required

```

--------------------------------

### Example Usage of RunFunction

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/function-type.md

Demonstrates how to create a Function instance and execute its RunFunction method. This is typically called by a gRPC server.

```go
import (
	"context"
	"github.com/crossplane/function-sdk-go/logging"
	fnv1 "github.com/crossplane/function-sdk-go/proto/v1"
)

// Create function instance
log, _ := logging.NewLogger(false)
fn := &Function{
	log: log,
	TTL: 120 * time.Second,
}

// Execute the function (typically called by gRPC server)
request := &fnv1.RunFunctionRequest{
	// Populated by Crossplane composition engine
}

response, err := fn.RunFunction(context.Background(), request)
if err != nil {
	log.Error("Failed to run function", "err", err)
}
```

--------------------------------

### Ready Ingress Example (Multiple Ingress Points)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-ingress.md

Illustrates a Kubernetes Ingress resource that is ready, featuring multiple external endpoints assigned by the load balancer.

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 80
status:
  loadBalancer:
    ingress:
    - hostname: ingress-1.example.com
      ports:
      - port: 80
        protocol: TCP
    - hostname: ingress-2.example.com
      ports:
      - port: 80
        protocol: TCP
```

--------------------------------

### Example: DaemonSet Rolling Update in Progress

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-daemonset.md

This example demonstrates a DaemonSet during a rolling update. The `updatedNumberScheduled` is less than `desiredNumberScheduled`, indicating that not all pods have been updated to the new version yet.

```yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluentd:v1.15
status:
  desiredNumberScheduled: 3
  updatedNumberScheduled: 2
  numberReady: 3
  numberAvailable: 3
  observedGeneration: 2
```

--------------------------------

### YAML: LoadBalancer Service (Ready)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-service.md

An example of a ready LoadBalancer Service with an assigned ingress endpoint.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer-service
  namespace: default
spec:
  type: LoadBalancer
  selector:
    app: MyApp
  ports:
  - port: 80
    targetPort: 9376
status:
  loadBalancer:
    ingress:
    - hostname: a1234567890abcdef-1234567890.us-east-1.elb.amazonaws.com
      ports:
      - port: 80
        protocol: TCP
```

--------------------------------

### Example Health Check Implementation

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthchecks-registry.md

An example implementation of a health check function for a ConfigMap. This specific check always returns true, assuming ConfigMaps are ready if they exist.

```go
func checkConfigMapHealth(obj *unstructured.Unstructured) bool {
	// ConfigMaps are always ready if they exist
	return true
}
```

--------------------------------

### Suspended Job Example

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-job.md

This example shows a Kubernetes Job that is not ready because it is suspended, as indicated by the 'Suspended' condition with a 'True' status.

```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: suspended-job
spec:
  suspend: true
  template:
    spec:
      containers:
      - name: worker
        image: busybox:1.28
        command: ["sh", "-c", "sleep 300"]
      restartPolicy: Never
status:
  conditions:
  - type: Suspended
    status: "True"
    reason: "JobSuspended"
    message: "Job suspended by user"
  - type: Complete
    status: "False"
  active: 0
```

--------------------------------

### Ready Ingress Example (LoadBalancer Assigned Hostname)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-ingress.md

Demonstrates a Kubernetes Ingress resource that is considered ready because the load balancer has assigned an external hostname.

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 80
status:
  loadBalancer:
    ingress:
    - hostname: a1234567890abcdef-1234567890.us-east-1.elb.amazonaws.com
```

--------------------------------

### Example of a Ready Deployment

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-deployment.md

This YAML defines a Kubernetes Deployment that is considered ready. All desired replicas are updated and available, and the 'Available' condition is true.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
status:
  observedGeneration: 1
  replicas: 3
  updatedReplicas: 3
  readyReplicas: 3
  availableReplicas: 3
  conditions:
  - type: Available
    status: "True"
    lastUpdateTime: 2024-01-15T10:30:00Z
    lastTransitionTime: 2024-01-15T10:30:00Z
    reason: MinimumReplicasAvailable
    message: "Deployment has minimum availability."
  - type: Progressing
    status: "True"
    lastUpdateTime: 2024-01-15T10:30:00Z
    lastTransitionTime: 2024-01-15T10:29:00Z
    reason: NewReplicaSetAvailable
    message: "ReplicaSet \"nginx-deployment-7d58b8c56\" has successfully progressed."
```

--------------------------------

### DaemonSet Status Example

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-daemonset.md

Illustrates a DaemonSet status where the number of available pods is less than the desired number, resulting in a 'Ready: false' state.

```yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      name: fluentd
status:
  desiredNumberScheduled: 3
  updatedNumberScheduled: 3
  numberReady: 3
  numberAvailable: 2
  observedGeneration: 1
```

--------------------------------

### Kubernetes Deployment Example

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/configuration.md

A sample Kubernetes Deployment manifest for running the function-auto-ready container. It includes volume mounts for TLS certificates and specifies command-line arguments.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: function-auto-ready
spec:
  replicas: 1
  selector:
    matchLabels:
      app: function-auto-ready
  template:
    metadata:
      labels:
        app: function-auto-ready
    spec:
      containers:
      - name: function
        image: function-auto-ready:v0.1.0
        args:
        - --tls-server-certs-dir=/etc/tls/certs
        - --address=:9443
        - --ttl=2m
        ports:
        - containerPort: 9443
          name: grpc
        volumeMounts:
        - name: tls-certs
          mountPath: /etc/tls/certs
          readOnly: true
      volumes:
      - name: tls-certs
        secret:
          secretName: function-tls-certs
```

--------------------------------

### Failed Job Example (Exceeded backoff limit)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-job.md

This example shows a Kubernetes Job that is not ready because its 'Failed' condition is 'True', indicating an issue like exceeding the backoff limit.

```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: failing-job
spec:
  template:
    spec:
      containers:
      - name: failing-container
        image: busybox:1.28
        command: ["sh", "-c", "exit 1"]
      restartPolicy: Never
  backoffLimit: 3
status:
  conditions:
  - type: Failed
    status: "True"
    lastProbeTime: 2024-01-15T10:35:00Z
    lastTransitionTime: 2024-01-15T10:35:00Z
    reason: BackoffLimitExceeded
    message: "Job has reached the specified backoff limit"
  - type: Complete
    status: "False"
  failed: 4
  active: 0
```

--------------------------------

### Ingress Example (LoadBalancer Provisioning)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-ingress.md

Represents a Kubernetes Ingress resource during the provisioning phase, where the load balancer has not yet assigned any external endpoints.

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 80
status:
  loadBalancer:
    ingress: []
```

--------------------------------

### Example of a Deploying Deployment

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-deployment.md

This YAML defines a Kubernetes Deployment that is currently deploying. Not all replicas have been updated yet, resulting in a 'Ready: false' status.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
status:
  observedGeneration: 2
  replicas: 3
  updatedReplicas: 2
  readyReplicas: 2
  availableReplicas: 2
  conditions:
  - type: Available
    status: "True"
```

--------------------------------

### Ready Ingress Example (LoadBalancer Assigned IP Address)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-ingress.md

Shows a Kubernetes Ingress resource that is ready because the load balancer has assigned an external IP address.

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 80
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.1
```

--------------------------------

### YAML: LoadBalancer Service (Provisioning)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-service.md

An example of a LoadBalancer Service still in provisioning, indicated by an empty ingress list.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer-service
  namespace: default
spec:
  type: LoadBalancer
  selector:
    app: MyApp
  ports:
  - port: 80
    targetPort: 9376
status:
  loadBalancer:
    ingress: []
```

--------------------------------

### Generate TLS Certificates

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/configuration.md

Example commands for generating CA keys and certificates, server keys and CSRs, and signing server certificates with a CA using OpenSSL.

```bash
# Generate CA key and certificate
openssl genrsa -out ca.key 2048
openssl req -new -x509 -days 365 -key ca.key -out ca.crt

# Generate server key and certificate signing request
openssl genrsa -out tls.key 2048
openssl req -new -key tls.key -out tls.csr

# Sign server certificate with CA
openssl x509 -req -in tls.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out tls.crt -days 365 \
  -extensions v3_alt -extfile <(printf "subjectAltName=DNS:localhost,IP:127.0.0.1")
```

--------------------------------

### Suspended CronJob Example

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-cronjob.md

Demonstrates a suspended CronJob. Suspended CronJobs are considered ready as suspension is a valid operational state.

```yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 0 * * *"
  suspend: true
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            command: ["echo", "hello world"]
          restartPolicy: OnFailure
status:
  lastScheduleTime: null
```

--------------------------------

### CronJob with Active Job Example

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-cronjob.md

Illustrates a CronJob that has an active job running. The presence of active jobs indicates readiness.

```yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 0 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
          restartPolicy: OnFailure
status:
  lastScheduleTime: 2024-01-15T00:00:00Z
  lastSuccessfulTime: 2024-01-14T00:00:00Z
  active:
  - name: hello-28392749
    namespace: default
```

--------------------------------

### StatefulSet Status Example

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-statefulset.md

Illustrates a StatefulSet where not all replicas are ready. This condition results in the health check reporting 'Ready: false' because spec.replicas does not equal status.readyReplicas.

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: nginx
  replicas: 3
status:
  observedGeneration: 1
  replicas: 3
  readyReplicas: 2
  currentReplicas: 3
  updatedReplicas: 3
  currentRevision: web-abc123def456
  updateRevision: web-abc123def456
```

--------------------------------

### Function Auto-Ready Source Code Structure

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/architecture-overview.md

Illustrates the directory layout and key files within the function-auto-ready project, including the main handler, tests, health checks, and example compositions.

```tree
function-auto-ready/
├── fn.go                          # Main function handler
├── fn_test.go                     # Function tests
├── main.go                        # CLI and server setup
├── healthchecks/
│  ├── registry.go                # Health check registry
│  ├── registry_test.go           # Registry tests
│  ├── pod.go, pod_test.go        # Pod health check
│  ├── deployment.go              # Deployment health check
│  ├── [other checks].go          # Other resource checks
│  └── *_test.go                  # Unit tests
├── go.mod, go.sum                # Dependencies
├── Dockerfile                    # Container build
├── package/                      # Crossplane package metadata
└── example/                      # Example compositions
```

--------------------------------

### Ingress Example (Missing LoadBalancer Status)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-ingress.md

Shows a Kubernetes Ingress resource where the `status.loadBalancer` field is entirely missing, indicating no load balancer information is available.

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 80
status: {}
```

--------------------------------

### Bound PVC Example (Ready)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-persistentvolumeclaim.md

This YAML defines a PersistentVolumeClaim that is in the 'Bound' phase, indicating it is successfully bound to a PersistentVolume and ready for use. The expected result is Ready: true.

```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard
status:
  phase: Bound
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 10Gi
  volumeName: pv-abc123

```

--------------------------------

### Run Method Signature

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/cli-type.md

Represents the method signature for the Run function of the CLI type. It initializes and starts the gRPC server based on the configured CLI options.

```go
func (c *CLI) Run() error
```

--------------------------------

### Example: Spec Update Not Yet Observed

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-replicaset.md

Illustrates a ReplicaSet where the spec has been updated, but the controller has not yet observed the change, leading to a 'Ready: false' status.

```yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  generation: 2  # Spec was updated
spec:
  replicas: 5
  selector:
    matchLabels:
      tier: frontend
status:
  replicas: 3
  availableReplicas: 3
  observedGeneration: 1  # Controller hasn't processed update yet
  conditions: []
```

--------------------------------

### Check Metrics Server Installation

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-hpa.md

This bash command verifies if the metrics-server deployment is running in the kube-system namespace. It's a prerequisite for using resource-based metrics like CPU and memory.

```bash
kubectl get deployment metrics-server -n kube-system
```

--------------------------------

### Pending PVC Example (Waiting for Volume)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-persistentvolumeclaim.md

This YAML defines a PersistentVolumeClaim in the 'Pending' phase, signifying it is waiting for a suitable PersistentVolume. The expected result is Ready: false.

```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast-ssd
status:
  phase: Pending
  accessModes:
    - ReadWriteOnce

```

--------------------------------

### Module Organization

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/README.md

Illustrates the directory structure of the function-auto-ready project, highlighting key files and their purposes.

```go
github.com/crossplane/function-auto-ready
├── fn.go — Function handler and RunFunction() implementation
├── main.go — CLI parsing and gRPC server setup
├── healthchecks/ — Health check implementations
│  ├── registry.go — Health check registry and registration
│  ├── pod.go, deployment.go, ... — Individual resource checks
│  └── *_test.go — Unit tests for each check
├── package/ — Crossplane function package metadata
└── example/ — Example compositions demonstrating usage

```

--------------------------------

### Render Composition (Basic)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/example/README.md

Use this command to see the resources a composition will create without considering their current state. Resources will not be marked as ready as they do not yet exist.

```shell
crossplane render xr.yaml composition-k8s.yaml functions.yaml
```

--------------------------------

### Azure Application Gateway Ingress Status

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-ingress.md

Example of an Ingress status with an IP address when using Azure Application Gateway.

```yaml
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.2
```

--------------------------------

### GCP Load Balancer Ingress Status

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-ingress.md

Example of an Ingress status with an IP address when using GCP Load Balancer.

```yaml
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.1
```

--------------------------------

### Run Function Tests

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/README.md

Execute the unit tests for the function-auto-ready using Go's testing framework.

```shell
$ go test ./...
```

--------------------------------

### AWS Load Balancer Ingress Status

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-ingress.md

Example of an Ingress status with a hostname when using the AWS Load Balancer Controller.

```yaml
status:
  loadBalancer:
    ingress:
    - hostname: k8s-default-example-abc123def-1234567890.us-west-2.elb.amazonaws.com
```

--------------------------------

### Render Composition with Observed Resources

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/example/README.md

Simulate existing Kubernetes resources with populated status fields to test readiness detection. This command renders the desired state, reflecting the function's behavior after resources have been created and their statuses updated.

```shell
crossplane render xr.yaml composition-k8s.yaml functions.yaml -o observed-k8s.yaml
```

--------------------------------

### Bare Metal MetalLB Ingress Status

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-ingress.md

Example of an Ingress status with an IP address when using MetalLB for bare metal environments.

```yaml
status:
  loadBalancer:
    ingress:
    - ip: 192.168.1.100
```

--------------------------------

### StatefulSet Readiness: Desired Replicas Match Ready Replicas

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-statefulset.md

Verifies that all desired replicas are in the Ready state. This indicates that pods have passed their readiness probes.

```yaml
spec.replicas == status.readyReplicas
```

--------------------------------

### main() Function

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/cli-type.md

The entry point of the application that parses command-line arguments and executes the CLI's Run method.

```APIDOC
## main() Function

### Description
Entry point that parses command-line arguments and runs the CLI.

### Behavior
1. Parses command-line arguments using `kong.Parse()` with a new `CLI` instance.
2. Executes the `Run()` method on the parsed CLI.
3. Calls `FatalIfErrorf()` to exit with an error message if `Run()` fails.

### Command-Line Usage Examples

```bash
# Run with default settings (insecure mode)
./function-auto-ready --insecure

# Run with mTLS enabled
./function-auto-ready \
  --tls-server-certs-dir=/etc/tls \
  --address=0.0.0.0:9443

# Run with debug logging and custom TTL
./function-auto-ready \
  -d \
  --insecure \
  --ttl=90s

# Run with large message size support
./function-auto-ready \
  --insecure \
  --max-recv-message-size=16
```

### Environment Variables

| Variable | Purpose |
|---|---|
| `TLS_SERVER_CERTS_DIR` | Path to directory containing TLS certificates (alternative to `--tls-server-certs-dir` flag) |
```

--------------------------------

### StatefulSet Missing Revision Example

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-statefulset.md

Shows a StatefulSet where the updateRevision is missing. This scenario also leads to 'Ready: false' as a required revision field is not found.

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: nginx
  replicas: 3
status:
  observedGeneration: 1
  replicas: 3
  readyReplicas: 3
  currentReplicas: 3
  updatedReplicas: 3
  currentRevision: web-abc123def456
  # updateRevision missing
```

--------------------------------

### Build Function Runtime Image

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/README.md

Build the Docker image for the function-auto-ready runtime using the provided Dockerfile.

```shell
$ docker build . --tag=runtime
```

--------------------------------

### StatefulSet Decision Tree Logic

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-statefulset.md

Illustrates the decision-making process for determining StatefulSet readiness, including replica counts and revision comparisons.

```text
┌─ Get spec.replicas (default: 1)
├─ Get status.readyReplicas
│  └─ Not found → Ready: false
├─ Get status.currentReplicas
│  └─ Not found → Ready: false
├─ Check replica counts match
│  ├─ spec != readyReplicas → Ready: false
│  ├─ spec != currentReplicas → Ready: false
│  └─ Both match → Continue
├─ Get status.currentRevision
│  └─ Not found → Ready: false
├─ Get status.updateRevision
│  └─ Not found → Ready: false
└─ Compare revisions
   ├─ currentRevision == updateRevision → Ready: true
   └─ currentRevision != updateRevision → Ready: false (rolling update in progress)
```

--------------------------------

### Registry Initialization Calls

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthchecks-registry.md

Shows the calls made during package initialization to register health checks for various standard Kubernetes resources.

```go
func init() {
	registerConfigMapHealthCheck()
	registerCronJobHealthCheck()
	registerDaemonSetHealthCheck()
	registerDeploymentHealthCheck()
	registerHorizontalPodAutoscalerHealthCheck()
	registerIngressHealthCheck()
	registerJobHealthCheck()
	namespaceHealthCheck()
	registerPersistentVolumeClaimHealthCheck()
	registerPodHealthCheck()
	registerReplicaSetHealthCheck()
	registerSecretHealthCheck()
	registerServiceHealthCheck()
	registerServiceAccountHealthCheck()
	registerStatefulSetHealthCheck()
}
```

--------------------------------

### DaemonSet Readiness Criteria: Available Pods

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-daemonset.md

This check verifies that all desired pods are not only running but also available. Availability implies that a pod has been ready for a minimum configured duration, ensuring stability.

```yaml
status.numberAvailable == status.desiredNumberScheduled
```

--------------------------------

### Pod Readiness Criteria: Pending Phase

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-pod.md

Pods in the Pending phase are still initializing and not ready.

```yaml
Pod.Status.Phase == PodPending → Ready: false
```

--------------------------------

### StatefulSet Readiness: Desired Replicas Match Current Replicas

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-statefulset.md

Confirms that all desired replicas are at the current revision. Combined with the revision match, this ensures all replicas are on the new version.

```yaml
spec.replicas == status.currentReplicas
```

--------------------------------

### Lost PVC Example (Underlying PV Deleted)

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-persistentvolumeclaim.md

This YAML defines a PersistentVolumeClaim in the 'Lost' phase, indicating that its associated PersistentVolume has been deleted. The expected result is Ready: false.

```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
status:
  phase: Lost

```

--------------------------------

### Replica Count Handling Logic

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-replicaset.md

Demonstrates how the desired replica count is determined, defaulting to 1 if not explicitly set in the ReplicaSet spec.

```go
desiredReplicas := int32(1)
if rs.Spec.Replicas != nil {
	desiredReplicas = *rs.Spec.Replicas
}
```

--------------------------------

### Get Registered Health Check Function

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthchecks-registry.md

Retrieves a registered health check function for a given GroupVersionKind. Returns nil if no health check is found for the specified type.

```go
import (
	"k8s.io/apimachinery/pkg/apis/meta/v1/unstructured"
	"github.com/crossplane/function-auto-ready/healthchecks"
)

obj := &unstructured.Unstructured{
	Object: map[string]interface{}{
		"apiVersion": "apps/v1",
		"kind": "Deployment",
	},
}

gvk := obj.GroupVersionKind()
if healthCheck := healthchecks.GetHealthCheck(gvk); healthCheck != nil {
	isReady := healthCheck(obj)
	if isReady {
		fmt.Println("Deployment is ready")
	}
}
```

--------------------------------

### HPA Status: Failed to Get Metrics

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-hpa.md

This HPA configuration shows a 'FailedGetResourceMetric' condition, meaning metrics for a resource could not be computed. This scenario also leads to the HPA being not ready.

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
status:
  currentReplicas: 1
  desiredReplicas: 1
  conditions:
  - type: ScalingActive
    status: "False"
    reason: FailedGetResourceMetric
    message: "unable to compute metrics for resource cpu"
```

--------------------------------

### Render Crossplane Resources Locally

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/README.md

Command to render Crossplane XR, Composition, and function configurations locally. Use the '-o observed-k8s.yaml' flag to test with observed resources that simulate pre-existing resources.

```shell
$ crossplane render xr.yaml composition.yaml functions.yaml
```

```shell
$ crossplane render xr.yaml composition-k8s.yaml functions.yaml -o observed-k8s.yaml
```

--------------------------------

### HPA Status: Failed to Get Scale

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/api-reference/healthcheck-hpa.md

This HPA configuration demonstrates a 'FailedGetScale' condition, indicating the controller could not retrieve the target's current scale. This results in the HPA being not ready.

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: non-existent
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
status:
  currentReplicas: 0
  desiredReplicas: 0
  conditions:
  - type: AbleToScale
    status: "False"
    reason: FailedGetScale
    message: "the HPA controller was unable to get the target's current scale"
  - type: ScalingActive
    status: "False"
```

--------------------------------

### Project Structure

Source: https://github.com/crossplane-contrib/function-auto-ready/blob/main/_autodocs/MANIFEST.md

Illustrates the directory layout of the crossplane-contrib/function-auto-ready project, showing the organization of README, architecture, configuration, types, API reference, and manifest files.

```tree
output/
├── README.md                              # Main index and navigation
├── architecture-overview.md               # System design and concepts
├── configuration.md                       # Deployment and setup
├── types.md                              # Type definitions
├── api-reference/
│  ├── function-type.md                   # Core handler
│  ├── cli-type.md                        # Server configuration
│  ├── healthchecks-registry.md           # Registry system
│  ├── healthcheck-pod.md                 # Pod resource
│  ├── healthcheck-deployment.md          # Deployment resource
│  ├── healthcheck-service.md             # Service resource
│  ├── healthcheck-job.md                 # Job resource
│  ├── healthcheck-statefulset.md         # StatefulSet resource
│  ├── healthcheck-daemonset.md           # DaemonSet resource
│  ├── healthcheck-replicaset.md          # ReplicaSet resource
│  ├── healthcheck-cronjob.md             # CronJob resource
│  ├── healthcheck-ingress.md             # Ingress resource
│  ├── healthcheck-hpa.md                 # HPA resource
│  └── healthcheck-persistentvolumeclaim.md # PVC resource
└── MANIFEST.md                           # This file
```