What’s New for Compatibility Matrix
We now have support for multi-node OpenShift clusters. Most customer environments that run OpenShift have multiple nodes. With this enhancement, a vendor can now create OpenShift 4.13 and 4.14 clusters with up to 10 nodes and test their application using the default OpenShift storage and networking providers. (Note: This feature will not be delivered for OpenShift 4.11 and 4.12.)
We added EKS 1.23 and 1.24 as "Extended Support" Kubernetes distributions. While 1.23 and 1.24 are past EOL for upstream Kubernetes, Amazon continues to support them at an additional charge. In order to continue to deliver customer representative environments in Compatibility Matrix, we are continuing to support EKS 1.23 and 1.24, but these will have additional charges billed for these clusters. Instead of our normal $0.50 cluster charge, these extended support EKS versions will be billed at $1 per cluster, and we are adding in a $3 per hour (billed in per-minute increments) for the time these clusters are running. Additional pricing information is available on our website.
You can now deploy EKS clusters with multiple node groups. Previously, CMX clusters could have multiple nodes, but each node had to be the same instance type. With support for node groups for EKS clusters, vendors can begin to deploy clusters that include multiple instance types. Each node group contains one or more nodes of a particular instance type. This also enables vendors to add GPU and ARM nodes to a cluster when they need a mix of node types in one cluster. See [.inline]--nodegroup[.inline] in the CLI docs.
There are new kind versions available. Previously with kind v0.20.0, we supported a limited number of Kubernetes versions. With kind v0.22.0, we now support a broader list of Kubernetes versions, going back to Kubernetes 1.23. The following versions can be selected: 1.23.17, 1.24.17, 1.25.16, 1.26.14, 1.27.11, 1.28.7, 1.29.2. See kind in the docs.
What’s New for Vendor Portal
Vendors can now add a custom ID to a customer. Setting a custom ID (such as a Salesforce ID, Hubspot ID, etc) allows a vendor to easily tie a given Replicated customer to their own internal customer data systems during data exports. This custom ID does not replace the Replicated-generated customer ID, but rather complements it to make identifying customers that much easier. Vendors can set the custom ID via the Vendor Portal UI, API, or CLI. Once set, the information is displayed on the relevant customer, and is searchable by API or within the UI itself, as well as included in any data exports of customer/instance data.
- Docs: Custom ID can be leveraged when Creating or Updating a Customer or when Filtering & Searching Customers within the UI, or via theAPI when Creating a Customer; Updating a Customer or Searching for a Customer (custom ID should be passed as part of query param for this endpoint)
The [.inline] /customer_instances [.inline] endpoint can now be further filtered by customer IDs. While Vendors can already pull a JSON payload of custom metrics and other application instance data via Vendor API, this endpoint previously returned one large response for all customers. With the addition of the filter by customer ID option, such as [.inline] /customer_instances?customerIds=xxx,yyy,zzz [.inline], you can now further filter the response returned to specific customers of interest.
There are now improved proxy registry image access controls available - reach out to us for access. Traditionally, all licenses for a team can access all application images in linked registries. Customers who opt-in can now leverage a new API endpoint that accepts a payload containing a list of images that a customer can access. When present on a customer record, only the allowed images can be pulled during an online installation. If your organization would benefit from this feature, please reach out to your account manager.
There are now improved controls to pin an end-customer license to a specific version - reach out to us for access. Traditionally a customer license will have access to pull the latest application version available on their assigned release channel. For Vendors who may need to keep specific customers on older application versions, this has meant having to create and manage customer specific release channels with those desired versions as “latest”. With this new application versioning pinning capability, Vendors can now pin a particular end-customer license to any prior app release on their assigned channel, and the end customer will only see that version available as latest via KOTS and the Download Portal. If your organization would benefit from this feature, please reach out to your account manager.
Improved validation of support bundles uploaded for Alpha air gap telemetry capability. Airgap telemetry collection via support bundle extraction requires a valid support bundle with instance data available. As part of the path to Beta for this feature, we’ve added improved support bundle validation. Vendors using this airgap telemetry capability will now be told if an uploaded support bundle has errors that could block telemetry extraction, such as a missing or invalid license ID, instance ID, and/or events record. If errors are found, these bundles will still be accessible under Troubleshoot with error information. If the bundle can be successfully validated, the vendor can then choose to go to the support bundle screen or dive into the insights data for that air gap instance. Reach out to us if you’d like early access to the airgap telemetry feature.
Vendors can now more easily connect Google Artifact Registry. We’ve added Artifact Registry as an option when connecting an external registry (docs). We’ve also improved the naming and helper text for each registry option to make it more obvious what vendors should enter for that particular registry.
What’s New for the Embedded Cluster
Single-node embedded cluster Beta! Single-node, online embedded cluster installations are now in Beta! This is the easiest way to deploy your Kubernetes application on a VM without requiring Kubernetes knowledge from your customers. Multi-node support is available in Alpha, and air gap support is on the way. The Beta is available for two minor versions of Kubernetes, in embedded cluster versions 1.28.7+ec.1 and later and 1.29.2+ec.1 and later. Check out the announcement blog and documentation.
What’s New for Product Documentation
There's a new Replicated platform diagram that demonstrates how Replicated features can be used together to distribute software:
There’s a new tutorial on adding preflights to a Helm chart. A new Add Preflights to a Helm Chart tutorial walks users through how to define a preflight spec in a Kubernetes Secret in the templates of a sample Helm chart, and then run preflights as part of installation. This tutorial fills a gap in the docs to provide an end-to-end workflow of adding and running preflights, helping to get users started with the feature.