kOps

The cloudmock package provides a mock implementation of the CloudProvider APIs. It is designed to allow testing of code that interacts with cloud providers without creating actual physical resources.

Key characteristics:

• Stateful Simulation: While no real resources are created, cloudmock maintains internal state. For example, calling CreateVpc will cause a subsequent call to DescribeVpcs to return the newly created VPC.
• Purpose: It enables fast, cost-effective testing of logic that would otherwise require real cloud infrastructure.
• Limitations: The APIs are extensive and most are not implemented. Implemented functions may not handle edge cases or error handling with perfect accuracy.

To use it in an AWS context, you can instantiate a MockEC2 client, which implements the ec2iface.EC2API interface, allowing it to be swapped in for a real EC2 client in your tests.

c := &mockec2.MockEC2{}
// c can now be used anywhere an ec2iface.EC2API is required

kOps provides several advanced capabilities for managing Kubernetes infrastructure:

• Automated Provisioning: Automates the setup of Highly Available (HA) clusters.
• State-Sync Model: Supports dry-runs and provides idempotency (running the same command multiple times results in the same state without unintended side effects).
• Infrastructure as Code: Ability to generate Terraform configurations.
• Managed Add-ons: Supports zero-config managed Kubernetes add-ons.
• Configuration via API: Uses a YAML Manifest Based API for cluster configuration.
• Templating: Supports templating and dry-run modes for creating manifests.
• Networking: Out-of-the-box support for popular CNI (Container Network Interface) providers.
• Multi-architecture: Supports ARM64 architectures.
• Node Customization: Allows adding containers (as hooks) and files to nodes via a cluster manifest.

If you need a single entry in spec.addons to manage multiple versioned manifests, you can use a kOps Addons index. An Addons index defines a collection of addons, each with a name, version, selector, and a manifest path.

The manifest path in an Addons index is relative to the index file itself. For example, if your index file is addon.yaml, a manifest path of foo.addons.org.io/v0.0.1.yaml expects the file to exist at ./foo.addons.org.io/v0.0.1.yaml relative to the index.

Example Addons index structure:

kind: Addons
metadata:
  name: example
spec:
  addons:
  - name: foo.addons.org.io
    version: 0.0.1
    selector:
      k8s-addon: foo.addons.org.io
    manifest: foo.addons.org.io/v0.0.1.yaml
  - name: bar.addons.org.io
    version: 0.0.1
    selector:
      k8s-addon: bar.addons.org.io
    manifest: bar.addons.org.io/v0.0.1.yaml

Expected file layout:

addon.yaml
  foo.addons.org.io
    v0.0.1.yaml
  bar.addons.org.io
    v0.0.1.yaml

When an InstanceGroup is configured with spec.manager: Karpenter, kOps automatically generates and manages two Kubernetes resources via the karpenter.sh addon:

1. EC2NodeClass: Configures the AWS-specific settings. kOps maps the following from the InstanceGroup:

   • amiFamily: Custom
   • InstanceGroup image $\rightarrow$ amiSelectorTerms
   • spec.rootVolume $\rightarrow$ blockDeviceMappings
   • Node instance profile and security groups
   • Subnets tagged for the InstanceGroup
   • Nodeup bootstrap script $\rightarrow$ userData
   • spec.kubelet settings that affect scheduling (maxPods, systemReserved, kubeReserved) are mapped to EC2NodeClass.spec.kubelet.

2. NodePool: Defines the scaling logic. It references the generated EC2NodeClass and includes:

   • Linux as a requirement
   • Instance type and capacity type requirements from the InstanceGroup
   • Safe node labels and taints from the InstanceGroup
   • NodePool.spec.limits.nodes (mapped from maxSize if using static mode)

These objects are named after the InstanceGroup and are pruned automatically when the InstanceGroup is removed.