readinessPeriodSeconds: 15

      # Enables or disables a startup probe.
      # For optimal startup times, changing this should be tied to the readiness probe values.
      #
      # If the probe is enabled, it is recommended to have delay=0s,period=15s,failureThreshold=4.
      # This ensures the pod is marked ready immediately after the startup probe passes (which has a 1s poll interval),

		} else {
			// If oldpod != ready && newpod != ready, but the ambient annotation was added,
			// then assume this event was generated by the CNI plugin labeling the pod on startup,
			// and skip the event.
			//
			// This isn't perfect (someone could manually annotate an unready pod,
			// then install Istio, then the pod goes ready, and we'd miss capture) - but that

- CAP_SYS_ADMIN
- CAP_NET_ADMIN
- CAP_NET_RAW

## Ambient mode details

Fundamentally, this component is responsible for the following:

      readinessPeriodSeconds: 15
      # Enables or disables a startup probe.
      # For optimal startup times, changing this should be tied to the readiness probe values.
      #
      # If the probe is enabled, it is recommended to have delay=0s,period=15s,failureThreshold=4.
      # This ensures the pod is marked ready immediately after the startup probe passes (which has a 1s poll interval),

		return nil, nil, fmt.Errorf("check minimum supported Kubernetes version: %v", err)
	}
	return kubeClient, client, nil
}

// applyOptions contains the startup options for applying the manifest.
type applyOptions struct {
	// Path to the kubeconfig file.
	Kubeconfig string
	// ComponentName of the kubeconfig context to use.
	Context string

A queue is used to give a few properties:
* Ability to serially process updates received from a variety of different sources. This avoids need for other synchronization mechanisms like mutexes.
* Correctness at startup; with the sequencing above, items are only processed once all informers are synced. This means queries will not return stale data at startup.
* Deduping of identical events

                minimum: 10
                type: integer
            type: object
          status:
            description: BFDProfileStatus defines the observed state of BFDProfile.
            type: object
        type: object
    served: true
    storage: true
    subresources:
      status: {}
---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:

  // +optional
  optional NamespaceSpec spec = 2;

  // Status describes the current status of a Namespace.
  // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
  // +optional
  optional NamespaceStatus status = 3;
}

seconds. readinessInitialDela: 0 # The period between readiness probes. readinessPeriodSecon: 15 # Enables or disables a startup probe. # For optimal startup times, changing this should be tied to the readiness probe values. # # If the probe is enabled, it is recommended to have delay=0s,period=15s,failureThreshold=4. # This ensures the pod is marked ready immediately after the startup probe passes (which has a 1s poll interval), # and doesn't spam the readiness endpoint too much # # If the probe is disabled,...

However, there is also a bit of additional logic. Gateway types have extensive status reporting. Unlike Ingress, this is status reporting is done inline in the main controller, allowing status generation to be done directly in the logic processing the resources.

Additionally, Gateway involves two components writing to the cluster: