Current Limitations and Constraints¶
This document outlines the current limitations, constraints, and known issues with the Karpenter IBM Cloud Provider.
IBM Cloud Platform Limitations¶
Networking Constraints¶
Single Zone per NodeClass¶
- Limitation: Each IBMNodeClass can only specify one zone
- Impact: Cannot auto-balance across multiple zones in single NodeClass
- Workaround: Create multiple NodeClasses for different zones
# Required: Separate NodeClass per zone
---
apiVersion: karpenter.ibm.sh/v1alpha1
kind: IBMNodeClass
metadata:
name: nodeclass-us-south-1
spec:
zone: us-south-1
---
apiVersion: karpenter.ibm.sh/v1alpha1
kind: IBMNodeClass
metadata:
name: nodeclass-us-south-2
spec:
zone: us-south-2
No Multi-Zone Auto-Placement¶
- Status: Not implemented
- Impact: Manual zone specification required
Storage Limitations¶
Limited Storage Integration¶
- Current: Basic boot volume support only
- Missing:
- Dynamic storage provisioning during node creation
- Multiple storage attachments
- Custom storage profiles
- Workaround: Configure storage post-provisioning via storage classes
No Instance Store Support¶
- Status: Not implemented
- Impact: Cannot use local NVMe storage
- Alternative: Use IBM Cloud Block Storage
Provider-Specific Limitations¶
Bootstrap Mode Limitations¶
IKS Mode Instance Type Constraint¶
- Impact: When using IKS mode (when
iksClusterID
is specified orbootstrapMode: "iks-api"
), the provisioner cannot dynamically select instance types based on pod requirements - Root Cause: IKS Worker Pool Resize API (
PATCH /v1/clusters/{id}/workerpools/{poolId}
) adds nodes with instance types pre-configured in the worker pool - Current Behavior:
instanceProfile
andinstanceRequirements
fields in IBMNodeClass are ignored in IKS mode- All new nodes use the instance type configured in the existing worker pool
- Workarounds:
- Pre-create separate worker pools for different instance types
- Use multiple NodeClasses targeting different worker pools
# Example: Multiple NodeClasses for different instance types in IKS mode
---
apiVersion: karpenter.ibm.sh/v1alpha1
kind: IBMNodeClass
metadata:
name: small-instances
spec:
iksClusterID: "cluster-id"
iksWorkerPoolID: "worker-pool-small" # Pre-configured with small instances
---
apiVersion: karpenter.ibm.sh/v1alpha1
kind: IBMNodeClass
metadata:
name: large-instances
spec:
iksClusterID: "cluster-id"
iksWorkerPoolID: "worker-pool-large" # Pre-configured with large instances
Tagging and Metadata¶
Basic Tagging Support¶
- Current: Limited tag management
- Missing:
- Tag propagation from NodePool to instances
- Dynamic tag updates
- Cost allocation tags
No Interruption Detection¶
- Impact: Cannot preemptively handle instance interruptions
Networking Features¶
No Load Balancer Integration¶
- Missing: Automatic load balancer target registration
- Impact: Manual load balancer configuration required
- Workaround: Use Kubernetes ingress controllers
Limited Security Group Management¶
- Current: Uses default or specified security groups
- Missing: Dynamic security group creation and management
- Workaround: Pre-create security groups with required rules
Integration Limitations¶
Getting Help with Limitations¶
Report New Limitations¶
If you encounter limitations not documented here:
- Check existing issues: GitHub Issues
- Create new issue
- Provide context
Request Feature Priority¶
To prioritize development of specific features:
- Upvote existing issues: Show demand for features
- Comment with use case: Explain business impact
- Contribute: Submit PRs for high-priority features