Container & Kubernetes Management
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
Container & Kubernetes Management in ManageIQ provides a unified platform for discovering, monitoring, and controlling hybrid container environments. It enables the management of Kubernetes-based infrastructures, allowing administrators to gain insight into container workloads, infrastructure performance, and resource utilization. The system abstracts complex container orchestration entities into manageable objects such as Providers, Nodes, Pods (Groups), and Images.
The core of this system is the ContainerManager, which serves as the Extensible Management System (EMS) for container providers. It tracks the relationships between physical or virtual nodes and the containerized workloads they host, supporting features like metrics collection, performance trending, and compliance checking across multiple container orchestration platforms.
Core Architecture and Components
The architecture is built around the ContainerManager and a hierarchy of models that represent standard Kubernetes and container objects. These models are linked via active associations to maintain a real-time representation of the provider's state.
Data Model Hierarchy
The following diagram illustrates the relationship between the central ContainerManager and its child entities:
The hierarchy ensures that infrastructure (Nodes) is clearly separated from workloads (Pods/Groups) while maintaining strict association with management systems.
Sources: app/models/manageiq/providers/container_manager.rb:5-24, app/models/container_group.rb:23-32
Component Descriptions
| Component | Description | Derived Source |
|---|---|---|
| ContainerManager | The top-level provider model (EMS) managing all container resources. | container_manager.rb:4 |
| ContainerNode | Represents a worker or master node in a cluster; can live on virtual or physical hardware. | container_node.rb:1 |
| ContainerGroup | Also known as a Pod; a collection of containers sharing storage and network resources. | container_group.rb:1 |
| Container | An individual instance of a containerized application running within a group. | container.rb:1 |
| ContainerImage | The template used to create containers, often managed through Registries. | inventory/persister/builder/container_manager.rb:85 |
| ContainerProject | A Kubernetes Namespace used to partition resources within a cluster. | inventory/persister/builder/container_manager.rb:7 |
Resource and Workload Management
The platform tracks the operational state of resources using "Conditions" and provides summary insights into workload distribution.
Ready Conditions
Both Nodes and Groups implement a ready_condition to determine if they are operational. This is a virtual column derived from ContainerCondition records.
Sources: app/models/container_node.rb:39-41, app/models/container_group.rb:51-57
Workload Summaries
ContainerGroup provides a summary of container states (e.g., Running, Pending, Failed) to allow high-level monitoring of Pod health.
def container_states_summary
containers.group(:state).count.symbolize_keys
end
def running_containers_summary
summary = container_states_summary
"#{summary[:running] || 0}/#{summary.values.sum}"
end
Sources: app/models/container_group.rb:63-71
Inventory Persistence and Refresh
ManageIQ uses a Persister pattern to synchronize the state of the container provider with the internal database. The Inventory::Persister::Builder::ContainerManager defines how various collections are mapped and identified.
Manager References (Refs)
To uniquely identify objects during refresh, the system defines specific attributes as manager_ref:
- ContainerImages: Identified by
image_ref. - ContainerImageRegistries: Identified by
hostandport. - ContainerLimitItems: Identified by
container_limit,resource, anditem_type. - ContainerVolumes: Identified by
parentandname.
Sources: app/models/manageiq/providers/inventory/persister/builder/container_manager.rb:85-115
Secondary References
The system also supports secondary lookups, such as finding a project by its name or a group by its project and name combined.
Sources: app/models/manageiq/providers/inventory/persister/builder/container_manager.rb:7-133
Deployment and Orchestration Integration
The MiqWorker::ContainerCommon module provides logic for deploying ManageIQ's own internal components (workers) as containerized workloads within a Kubernetes environment.
Worker Deployment Logic
When a worker is deployed into a containerized infrastructure, the system applies specific configuration patches for resource limits, image policies, and affinity.
Resource Constraints
The system enforces CPU and Memory thresholds for workers. Thresholds are converted from standard MB/Percentage units into Kubernetes-standard "Mi" and "m" (millicores) units.
- Memory: Formatted as
#{value / 1.megabyte}Mi. - CPU: Formatted as
#{((value / 100.0) * 1000).to_i}m.
Sources: app/models/miq_worker/container_common.rb:64-100
External Logging Integration
ContainerNode supports integration with external logging platforms (like ELK) via a pre-defined URI template. This allows users to pivot from the ManageIQ UI directly to log discovery for a specific node.
- Index Pattern:
.operations.* - Query Logic: Filters by hostname using Kubernetes labels or the internal node name.
Sources: app/models/container_node.rb:14-118
Conclusion
Container & Kubernetes Management within ManageIQ provides a robust framework for handling cloud-native infrastructures. By mapping complex Kubernetes concepts into a standardized inventory and providing integrated logic for deployment and resource tracking, it allows for effective discovery, monitoring, and scaling of containerized workloads alongside traditional virtualization.