kubernetes/kops · error
getting control plane VMSS network interfaces for API ingres
Error message
getting control plane VMSS network interfaces for API ingress status: %w
What it means
After locating the control plane VMSS, GetApiIngressStatus lists its network interfaces via NetworkInterface().ListScaleSetsNetworkInterfaces. This error wraps any failure from that Azure API call. It indicates kOps found the scale set but could not enumerate its NICs to collect private IP addresses for the API ingress status.
Source
Thrown at upup/pkg/fi/cloudup/azure/azure_cloud.go:342
}
var vmssName string
for _, scaleSet := range scaleSets {
val, ok := scaleSet.Tags[TagClusterName]
val2, ok2 := scaleSet.Tags[TagNameRolePrefix+TagRoleControlPlane]
val3, ok3 := scaleSet.Tags[TagNameRolePrefix+TagRoleMaster]
if ok && *val == cluster.Name && (ok2 && *val2 == "1" || ok3 && *val3 == "1") {
vmssName = *scaleSet.Name
break
}
}
if vmssName == "" {
return nil, fmt.Errorf("getting control plane VMSS name for API ingress status")
}
// Get masters scale set network interfaces and append to api ingress status
nis, err := c.NetworkInterface().ListScaleSetsNetworkInterfaces(context.TODO(), rg, vmssName)
if err != nil {
return nil, fmt.Errorf("getting control plane VMSS network interfaces for API ingress status: %w", err)
}
for _, ni := range nis {
if ni.Properties == nil || ni.Properties.Primary == nil || !*ni.Properties.Primary {
continue
}
for _, i := range ni.Properties.IPConfigurations {
if i.Properties == nil || i.Properties.PrivateIPAddress == nil {
continue
}
ingresses = append(ingresses, fi.ApiIngressStatus{
IP: *i.Properties.PrivateIPAddress,
})
}
}
if ingresses == nil {
return nil, fmt.Errorf("getting API ingress status")
}
}View on GitHub (pinned to 4c8573c808)
Solutions
- Re-run the command after confirming the cluster still exists (race/teardown scenarios usually self-resolve).
- Verify the service principal has Reader (or Network Contributor) on the resource group / Microsoft.Network access.
- Check the wrapped Azure error for throttling codes (429) and retry with backoff.
- Confirm the VMSS name found via tags still exists: az vmss show -g <rg> -n <vmssName>.
- Check connectivity/proxy settings to management.azure.com.
Example fix
null
Defensive patterns
Strategy: retry
Validate before calling
// Go: verify the VMSS still exists and RBAC allows listing NICs before the call
vmssClient, _ := armcompute.NewVirtualMachineScaleSetsClient(subID, cred, nil)
if _, err := vmssClient.Get(ctx, rg, vmssName, nil); err != nil {
return fmt.Errorf("scale set %s gone or inaccessible: %w", vmssName, err)
} Type guard
func isThrottled(err error) bool {
var respErr *azcore.ResponseError
return errors.As(err, &respErr) && respErr.StatusCode == 429
} Try / catch
status, err := cloud.GetApiIngressStatus(cluster)
if err != nil && strings.Contains(err.Error(), "network interfaces for API ingress status") {
if isThrottled(errors.Unwrap(err)) {
time.Sleep(retryAfter) // honor Retry-After, then retry
}
return err
} Prevention
- Don't tear down or rename the control plane VMSS while status/validate commands run.
- Retry with exponential backoff on 429/transient Azure errors.
- Grant Microsoft.Network read permissions to the kOps service principal.
- Avoid deleting cluster NICs manually; let kOps manage networking.
- Check proxy/firewall stability for long-running kOps operations.
When it happens
Trigger: GetApiIngressStatus calls ListScaleSetsNetworkInterfaces(ctx, rg, vmssName) and it returns an error: Azure API failure (auth, throttling, network) or the scale set/VMSS name no longer exists in the resource group by the time the NIC list call runs.
Common situations: Control plane VMSS deleted or renamed between the List and NIC-list calls (race during cluster teardown); Azure throttling during bulk operations; transient management-plane network errors; RBAC changes removing read access to network interfaces.
Related errors
- getting cluster control plane VMSS for API ingress status: %
- getting API ingress status
- expected exactly one subnet for InstanceGroup %q; subnets wa
- unexpected subnet type: for InstanceGroup %q; type was %s
- instance group must have the same min and max size in Azure,
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/ed0e6fd6e9164ab5.
Report an issue: GitHub.