cilium/cilium · warning

CEP deleted externally or significant informer delay

Error message

CEP deleted externally or significant informer delay

What it means

During CiliumEndpoint update, the synchronizer checks that the CEP still exists in the local informer cache before applying changes. If it does not exist while the context is still live, it concludes the CEP was deleted externally (or the informer is lagging) and returns this error to force a full re-init of the CEP on the next iteration. This is a deliberate error signal used to reset the sync state machine, not an unexpected crash.

Source

Thrown at pkg/endpointmanager/endpointsynchronizer.go:230

									if err != nil {
										scopedLog.Debug("Error getting indexed CiliumEndpoint from store", logfields.Error, err)
									} else {
										for _, cep := range objs {
											if cep.Namespace == cepOwner.GetNamespace() && cep.Name == cepName {
												cepExists = true
												break
											}
										}
									}
								}
							}
						}

						if !cepExists && ctx.Err() == nil {
							scopedLog.Warn("CEP was deleted externally or there is a significant delay on the CEP informer, will recreate on next iteration")
							needInit = true
							localCEP = nil
							return fmt.Errorf("CEP deleted externally or significant informer delay")
						}
					}
					scopedLog.Debug("Skipping CiliumEndpoint update because it has not changed")
					return nil
				}

				if needInit {
					state := e.GetState()
					// Don't bother to create if the
					// endpoint is already disconnecting
					if state == endpoint.StateDisconnecting ||
						state == endpoint.StateDisconnected {
						return nil
					}

					scopedLog.Debug("Getting CEP during an initialization")
					if firstTry {
						// First we try getting CEP from the API server cache, as it's cheaper.

View on GitHub (pinned to ac7b90affa)

Solutions

1. Usually benign: the controller recreates/re-initializes the CEP on the next iteration — verify the CEP reappears (kubectl get cep)
2. If persistent, check apiserver/informer health (watch latency, apiserver metrics) and agent CPU throttling
3. Look for external controllers or scripts deleting CEPs and remove/fix them
4. Confirm no CEP ownership conflicts between agents on the same node

// confirm the CEP actually exists before assuming external deletion
_, err := clientset.CiliumV2().CiliumEndpoints(ns).Get(ctx, name, metav1.GetOptions{})
if apierrors.IsNotFound(err) {
	log.Info("CEP confirmed deleted; recreation expected on next iteration")
}

if err := updateCEP(ctx, cep); err != nil {
	if strings.Contains(err.Error(), "CEP deleted externally") {
		log.Warn("CEP missing from cache; letting next iteration re-init it")
		return
	}
	return err
}

When it happens

Trigger: Another actor (kubectl delete, CEP owner change, operator, or another agent after a CEP ownership handoff) deleted the CEP, or the CEP informer cache lags behind apiserver state while the agent attempts an update.

Common situations: Manual kubectl delete ciliumendpoint; race with agent restart/migration where the new agent deleted the old CEP; informer lag under heavy apiserver load; node under memory pressure slowing watch delivery.

Related errors

• failed to get CiliumEndpoint store: %w
• failed to get CiliumEndpointSlice store: %w
• endpoint sync cannot take ownership of CEP: no pod
• endpoint sync cannot take ownership of CEP: no pod HostIP
• CiliumNetworkPolicy rule cannot have NodeSelector, use Ciliu

AI-assisted analysis of cilium/cilium@ac7b90affa (2026-08-31). Data as JSON: /api/errors/b9dd6095db788d05. Report an issue: GitHub.