Documentation
¶
Index ¶
- type ControllerManager
- func (cm *ControllerManager) FindContainer(containerID string) (*corev1.Pod, *corev1.ContainerStatus, bool)
- func (cm *ControllerManager) FindMirrorPod(hash string) (*corev1.Pod, error)
- func (cm *ControllerManager) FindPod(podID string) (*corev1.Pod, error)
- func (cm *ControllerManager) GetNamespace(name string) (*corev1.Namespace, error)
- func (cm *ControllerManager) GetNode() (*corev1.Node, error)
- func (cm *ControllerManager) ListNamespaces() ([]corev1.Namespace, error)
- func (cm *ControllerManager) Start(ctx context.Context)
- func (cm *ControllerManager) WaitCRDs(ctx context.Context, crds map[string]struct{}) error
- func (cm *ControllerManager) WaitCRDsWithResync(ctx context.Context, crds map[string]struct{}, resyncPeriod time.Duration) error
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type ControllerManager ¶
type ControllerManager struct {
Manager ctrlManager.Manager
// contains filtered or unexported fields
}
ControllerManager is responsible for running controller-runtime controllers, and interacting with Kubernetes API server in general. If you need to interact with Kubernetes API server, this is the place to start.
func Get ¶
func Get() *ControllerManager
func (*ControllerManager) FindContainer ¶
func (cm *ControllerManager) FindContainer(containerID string) (*corev1.Pod, *corev1.ContainerStatus, bool)
func (*ControllerManager) FindMirrorPod ¶
func (cm *ControllerManager) FindMirrorPod(hash string) (*corev1.Pod, error)
func (*ControllerManager) FindPod ¶
func (cm *ControllerManager) FindPod(podID string) (*corev1.Pod, error)
func (*ControllerManager) GetNamespace ¶
func (cm *ControllerManager) GetNamespace(name string) (*corev1.Namespace, error)
func (*ControllerManager) ListNamespaces ¶
func (cm *ControllerManager) ListNamespaces() ([]corev1.Namespace, error)
func (*ControllerManager) Start ¶
func (cm *ControllerManager) Start(ctx context.Context)
func (*ControllerManager) WaitCRDs ¶
func (cm *ControllerManager) WaitCRDs(ctx context.Context, crds map[string]struct{}) error
WaitCRDs waits for the specified Custom Resource Definitions (CRDs) to become available in the Kubernetes cluster using a simple event-driven approach. This method sets up an event handler that responds to CRD addition events and completes when all required CRDs are found. It does not perform periodic resyncs or cache refreshes, making it suitable for scenarios where CRDs are expected to be created shortly after startup and network connectivity is stable.
Use WaitCRDs when:
- You expect CRDs to be available soon after application startup
- Network connectivity to the API server is reliable
- You want minimal resource overhead (no periodic resyncs)
- The application can tolerate potentially missing CRDs that exist but weren't detected due to missed events or temporary network issues
Parameters:
- ctx: Context for cancellation
- crds: Map of CRD names to wait for (map keys are CRD names, values are ignored)
Returns:
- error: Non-nil if waiting fails or context is cancelled
func (*ControllerManager) WaitCRDsWithResync ¶ added in v1.7.0
func (cm *ControllerManager) WaitCRDsWithResync(ctx context.Context, crds map[string]struct{}, resyncPeriod time.Duration) error
WaitCRDsWithResync waits for the specified Custom Resource Definitions (CRDs) to become available with enhanced reliability through periodic cache resyncs and comprehensive error handling. This method first checks the existing cache for CRDs, then sets up an event handler with a configurable resync period to ensure missed events are recovered. The resync mechanism periodically refreshes the cache, making this approach more robust against network issues, missed events, or temporary API server connectivity problems.
Applications can use WaitCRDsWithResync when: - You need guaranteed detection of existing CRDs that might be missed due to timing issues - Network connectivity to the API server may be unreliable - You can afford the additional resource overhead of periodic resyncs for improved reliability - Long-running applications where CRDs might be created at any time during execution
The method performs an initial cache check for efficiency, avoiding unnecessary waiting if all required CRDs already exist. The resync period should be chosen based on your tolerance for detection delay versus resource usage.
Parameters:
- ctx: Context for cancellation
- crds: Map of CRD names to wait for (map keys are CRD names, values are ignored)
- resyncPeriod: How often to refresh the cache and re-evaluate existing CRDs
Returns:
- error: Non-nil if waiting fails or context is cancelled
Source Files