What's Actually Happening
You installed Istio on your Kubernetes cluster and expected automatic sidecar injection to add the Envoy proxy to every pod in your mesh. But some or all pods are running without the istio-proxy sidecar container. Traffic isn't being routed through the mesh, mTLS isn't working, you can't see traffic in Kiali, and your Istio policies aren't being enforced.
The Istio sidecar injector webhook should intercept pod creation requests and inject the istio-proxy container. When injection fails, pods run as standalone containers without mesh integration, breaking all Istio features including traffic management, observability, and security.
The Error You'll See
Istio sidecar injection failures manifest in different ways depending on the root cause:
```bash # When checking pod status $ kubectl get pods -n production NAME READY STATUS RESTARTS AGE frontend-abc123-xyz789 1/1 Running 0 5m backend-def456-uvw012 1/1 Running 0 5m
# Note: READY shows 1/1 instead of 2/2 (sidecar missing)
# When describing the pod $ kubectl describe pod frontend-abc123-xyz789 -n production Containers: frontend: Container ID: docker://abc123... Image: myapp/frontend:v1.2.3 Ready: true # No istio-proxy container listed!
# Istioctl analyze output $ istioctl analyze Warn [IST0102]: Pod "frontend-abc123-xyz789" is missing the Istio sidecar. Warn [IST0102]: Pod "backend-def456-uvw012" is missing the Istio sidecar. Info [IST0103]: The mesh has 2 pods that are missing sidecars.
Error [IST0104]: mTLS is not enabled for service "frontend" because sidecar is missing. Error [IST0106]: VirtualService "frontend-vs" is not being applied because no sidecar exists.
# When checking namespace label $ kubectl get namespace production -o yaml apiVersion: v1 kind: Namespace metadata: name: production # No istio-injection=enabled label!
# Kiali showing missing sidecars # Services appear as "No sidecar" in Kiali graph # Traffic flows bypass the mesh completely
# Webhook errors in istiod logs $ kubectl logs -n istio-system deployment/istiod 2026-04-08T10:15:23.456Z error sidecar-injector Failed to inject sidecar for pod production/frontend-abc123: webhook request timeout 2026-04-08T10:15:24.123Z error sidecar-injector Admission webhook "istio-sidecar-injector.istio-system.svc" denied request: namespace not enabled for injection
# Kubernetes events showing webhook failures $ kubectl get events -n production --field-selector reason=FailedInject LAST SEEN TYPE REASON OBJECT MESSAGE 2m Warning FailedInject pod/frontend-abc123 Sidecar injection webhook timeout
# Checking injector webhook status $ kubectl get mutatingwebhookconfigurations NAME WEBHOOKS AGE istio-sidecar-injector 1 30d # Webhook exists but may not be working
# Testing connectivity to webhook $ kubectl run test --image=curlimages/curl -it --rm -- curl -k https://istio-sidecar-injector.istio-system.svc:443/inject curl: (7) Failed to connect to istio-sidecar-injector.istio-system.svc port 443: Connection refused ```
Additional symptoms: - VirtualService and DestinationRule configurations have no effect - No traffic appears in Grafana Istio dashboards - mTLS not enforced between services - Service unable to reach other services via mesh routing - AuthorizationPolicies not being enforced - Pods can't resolve istiod.istio-system.svc - Connection timeouts when using Istio gateways
Why This Happens
- 1.Namespace Not Labeled for Injection: The namespace doesn't have the
istio-injection=enabledlabel. Istio's sidecar injector only processes pods in namespaces with this label (unless using explicit annotation). Without the label, the webhook skips the namespace entirely. - 2.Pod Annotation Explicitly Disabling Injection: The pod has the annotation
sidecar.istio.io/inject: "false"which overrides the namespace label and explicitly tells Istio not to inject the sidecar. This can be inherited from deployment templates. - 3.Istiod Webhook Service Not Running: The istiod deployment or the sidecar-injector service within istiod isn't running properly. The webhook endpoint is unreachable when pods are created, causing injection to fail silently.
- 4.MutatingWebhookConfiguration Misconfigured: The webhook configuration references the wrong service, wrong namespace, or has incorrect CABundle. The Kubernetes API server can't reach the webhook or can't verify its certificate.
- 5.Network Policies Blocking Webhook Traffic: Network policies in the istio-system namespace or in application namespaces prevent the Kubernetes API server from reaching the sidecar-injector webhook service.
- 6.Webhook Timeout or Rate Limiting: The webhook is overloaded or timing out due to high pod creation rates. Kubernetes has a 30-second timeout for admission webhooks; if istiod doesn't respond within that time, injection fails.
- 7.Istio Revision Mismatch: You're running multiple Istio control plane revisions, and pods are being created with a revision label that doesn't match an active istiod deployment.
- 8.Host Network Pods: Pods with
hostNetwork: trueare excluded from sidecar injection by default because the sidecar can't properly capture traffic from pods using the host's network namespace.
Step 1: Identify Which Pods Are Missing Sidecars
First, determine the scope of the problem by finding all pods without sidecar injection.
```bash # Get list of all pods and check READY status kubectl get pods --all-namespaces -o wide
# Pods should show 2/2 READY (or more with additional containers) # 1/1 indicates missing sidecar
# Use istioctl to find pods missing sidecars istioctl analyze
# More detailed check with istioctl istioctl proxy-status
# List pods missing sidecar explicitly kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.containers[*].name}{"\n"}{end}' | grep -v istio-proxy
# Check specific namespace kubectl get pods -n production -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].name}{"\n"}{end}'
# If istio-proxy is missing from the container list, injection failed
# Count pods with and without sidecars echo "Pods with sidecar:" kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.spec.containers[*].name}{"\n"}{end}' | grep -c istio-proxy
echo "Pods without sidecar:" kubectl get pods --all-namespaces -o json | jq -r '.items[] | select(.spec.containers[].name != "istio-proxy") | .metadata.name'
# Check for istio-proxy container in specific pod kubectl get pod frontend-abc123-xyz789 -n production -o json | jq '.spec.containers[].name'
# Check pod annotations that might disable injection kubectl get pod frontend-abc123-xyz789 -n production -o json | jq '.metadata.annotations'
# Look for sidecar.istio.io/inject annotation kubectl get pods --all-namespaces -o json | jq -r '.items[] | select(.metadata.annotations["sidecar.istio.io/inject"] == "false") | .metadata.namespace + "/" + .metadata.name' ```
Document which namespaces and pods are affected. This helps determine if the issue is namespace-wide or pod-specific.
Step 2: Check Namespace Injection Labels and Pod Annotations
Verify that namespaces are properly labeled for injection and pods don't have disabling annotations.
```bash # Check all namespace labels kubectl get namespaces -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels}{"\n"}{end}'
# More readable format kubectl get namespaces -o custom-columns='NAME:.metadata.name,LABELS:.metadata.labels'
# Check specific namespace for istio-injection label kubectl get namespace production -o yaml | grep -A5 metadata:
# Expected output should include: # labels: # istio-injection: enabled
# List namespaces with istio-injection enabled kubectl get namespaces -l istio-injection=enabled
# List namespaces without istio-injection label kubectl get namespaces -o json | jq -r '.items[] | select(.metadata.labels["istio-injection"] == null) | .metadata.name'
# Check deployment annotations that might affect pods kubectl get deployment frontend -n production -o yaml | grep -A20 annotations:
# Look for annotation overriding injection # sidecar.istio.io/inject: "false" disables injection
# Check all deployments for injection annotations kubectl get deployments --all-namespaces -o json | jq -r '.items[] | select(.spec.template.metadata.annotations["sidecar.istio.io/inject"] == "false") | .metadata.namespace + "/" + .metadata.name'
# Check for revision label that might point to wrong istiod kubectl get deployment frontend -n production -o yaml | grep istio.io/rev
# If revision label exists, verify matching istiod revision is active kubectl get deployment -n istio-system -l app=istiod -o jsonpath='{range .items[*]}{.metadata.labels}{"\n"}{end}' ```
Step 3: Verify Istiod and Sidecar Injector Are Running
Check that the Istio control plane components are healthy and the webhook service is accessible.
```bash # Check istiod deployment status kubectl get deployment -n istio-system
# Expected: istiod should show READY 1/1 or more
kubectl get pods -n istio-system -l app=istiod
# Check istiod pod health kubectl describe pod -n istio-system -l app=istiod
# Check istiod logs for webhook errors kubectl logs -n istio-system -l app=istiod --tail=100 | grep -i "sidecar|inject|webhook|error"
# Check istiod resource usage kubectl top pods -n istio-system
# Verify sidecar-injector service exists kubectl get svc -n istio-system
# Should see istiod service (sidecar-injector is part of istiod)
# Check service endpoints kubectl get endpoints -n istio-system istiod
# Endpoints should show istiod pod IP addresses
# Verify webhook is registered kubectl get mutatingwebhookconfigurations istio-sidecar-injector -o yaml
# Check webhook configuration details kubectl get mutatingwebhookconfigurations -o yaml | grep -A50 "istio-sidecar-injector"
# Test webhook connectivity from a test pod kubectl run webhook-test --image=curlimages/curl:7.85.0 -it --rm --restart=Never -- curl -vk https://istiod.istio-system.svc:15017/inject -d '{"apiVersion":"v1","kind":"Pod"}'
# If connection fails, webhook is not reachable
# Check istiod service port kubectl get svc istiod -n istio-system -o jsonpath='{.spec_ports[?(@.name=="https-webhook")]}'
# Port 15017 should be configured for webhook ```
Step 4: Check MutatingWebhookConfiguration
Examine the webhook configuration for issues that prevent the API server from reaching istiod.
```bash # Get full webhook configuration kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml
# Key fields to verify: # - service.name: should be "istiod" # - service.namespace: should be "istio-system" # - service.port: should be 15017 (or 443 for older Istio) # - caBundle: should contain valid certificate data # - namespaceSelector: should match istio-injection=enabled # - failurePolicy: should be Ignore or Fail
# Check CABundle is present kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o jsonpath='{.webhooks[0].clientConfig.caBundle}' | base64 -d | openssl x509 -text -noout
# If CABundle is empty or invalid, webhook won't work
# Check namespace selector kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o jsonpath='{.webhooks[0].namespaceSelector}'
# Should match istio-injection=enabled
# Check object selector (for pod-level filtering) kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o jsonpath='{.webhooks[0].objectSelector}'
# Check failure policy kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o jsonpath='{.webhooks[0].failurePolicy}'
# "Fail" means pod creation fails if webhook unavailable # "Ignore" means pod is created without sidecar if webhook fails
# Check timeout seconds kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o jsonpath='{.webhooks[0].timeoutSeconds}'
# Default is 30 seconds
# If webhook configuration is wrong, reinstall or fix it: # Check Istio operator config if using IstioOperator kubectl get istiooperator -n istio-system -o yaml ```
Step 5: Fix Namespace Labels for Injection
Add or correct the istio-injection label on affected namespaces.
```bash # Enable injection on a namespace kubectl label namespace production istio-injection=enabled --overwrite
# Verify label was applied kubectl get namespace production -o yaml | grep istio-injection
# For specific Istio revision (if using multiple revisions): kubectl label namespace production istio-injection=enabled istio.io/rev=default --overwrite
# Or for a specific revision: kubectl label namespace production istio.io/rev=1-18-0 --overwrite kubectl label namespace production istio-injection- --overwrite # Remove generic label when using revision
# Enable injection on all application namespaces for ns in production staging development app1 app2; do kubectl label namespace $ns istio-injection=enabled --overwrite done
# List namespaces after applying labels kubectl get namespaces -l istio-injection=enabled
# If label was already there, check for conflicting revision labels: kubectl get namespace production -o json | jq '.metadata.labels'
# Remove any conflicting labels kubectl label namespace production istio.io/rev- --overwrite
# Redeploy pods to get sidecar injection kubectl rollout restart deployment/frontend -n production ```
Note: Labeling a namespace only affects newly created pods. Existing pods need to be deleted and recreated to get sidecar injection.
Step 6: Remove Pod Annotations Disabling Injection
If pods have annotations explicitly disabling injection, remove them from the deployment template.
```bash # Check deployment for disabling annotations kubectl get deployment frontend -n production -o yaml | grep -B5 -A5 "sidecar.istio.io"
# If you see annotation like: # annotations: # sidecar.istio.io/inject: "false"
# Remove the annotation from deployment kubectl patch deployment frontend -n production --type=json -p='[{"op": "remove", "path": "/spec/template/metadata/annotations/sidecar.istio.io~1inject"}]'
# Or edit deployment directly kubectl edit deployment frontend -n production # Remove or change the annotation to "true"
# Check all deployments with injection disabled kubectl get deployments --all-namespaces -o json | jq -r '.items[] | select(.spec.template.metadata.annotations["sidecar.istio.io/inject"] == "false") | ["kubectl patch deployment " + .metadata.name + " -n " + .metadata.namespace + " --type=json -p=[{\"op\": \"remove\", \"path\": \"/spec/template/metadata/annotations/sidecar.istio.io~1inject\"}]"] | @sh'
# Execute fixes for all affected deployments: kubectl get deployments --all-namespaces -o json | jq -r '.items[] | select(.spec.template.metadata.annotations["sidecar.istio.io/inject"] == "false") | .metadata.namespace + "/" + .metadata.name' | while read dep; do NS=$(echo $dep | cut -d/ -f1) NAME=$(echo $dep | cut -d/ -f2) kubectl patch deployment $NAME -n $NS --type=json -p='[{"op": "remove", "path": "/spec/template/metadata/annotations/sidecar.istio.io~1inject"}]' done
# Check for hostNetwork pods that are excluded by default kubectl get pods --all-namespaces -o json | jq -r '.items[] | select(.spec.hostNetwork == true) | .metadata.namespace + "/" + .metadata.name'
# For hostNetwork pods, you need special configuration # Add annotation to allow injection: kubectl patch deployment hostnetwork-app -n production --patch ' spec: template: metadata: annotations: sidecar.istio.io/inject: "true" '
# However, hostNetwork pods require additional Istio configuration ```
Step 7: Fix Webhook Configuration Issues
If the webhook configuration is incorrect, repair or reinstall it.
```bash # Check if webhook CABundle is empty or invalid CA_BUNDLE=$(kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o jsonpath='{.webhooks[0].clientConfig.caBundle}') if [ -z "$CA_BUNDLE" ]; then echo "CABundle is empty, need to regenerate" fi
# Get current Istio revision REVISION=$(kubectl get istiooperator -n istio-system -o jsonpath='{.items[0].spec.revision}' 2>/dev/null || echo "default")
# Regenerate webhook configuration # Method 1: Restart istiod to regenerate webhook kubectl rollout restart deployment/istiod -n istio-system
# Wait for istiod to be ready kubectl rollout status deployment/istiod -n istio-system
# Method 2: Use istioctl to fix webhook istioctl experimental precheck
# Method 3: Manual webhook configuration fix # Get istiod certificate kubectl get secret istiod -n istio-system -o jsonpath='{.data.ca\.crt}' | base64 -d > /tmp/istio-ca.crt
# Update webhook CABundle CA_CERT=$(kubectl get secret istiod -n istio-system -o jsonpath='{.data.ca\.crt}') kubectl patch mutatingwebhookconfiguration istio-sidecar-injector --type=json -p='[{"op": "replace", "path": "/webhooks/0/clientConfig/caBundle", "value": "'$CA_CERT'"}]'
# Verify CABundle is now present kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o jsonpath='{.webhooks[0].clientConfig.caBundle}' | wc -c
# Check webhook service reference kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o jsonpath='{.webhooks[0].clientConfig.service}'
# Should show: # {"name":"istiod","namespace":"istio-system","port":15017,"path":"/inject"}
# If service is wrong, fix it: kubectl patch mutatingwebhookconfiguration istio-sidecar-injector --type=json -p='[{"op": "replace", "path": "/webhooks/0/clientConfig/service/name", "value": "istiod"}]' kubectl patch mutatingwebhookconfiguration istio-sidecar-injector --type=json -p='[{"op": "replace", "path": "/webhooks/0/clientConfig/service/namespace", "value": "istio-system"}]' kubectl patch mutatingwebhookconfiguration istio-sidecar-injector --type=json -p='[{"op": "replace", "path": "/webhooks/0/clientConfig/service/port", "value": 15017}]' ```
Step 8: Check and Fix Network Policies
Network policies might be blocking the Kubernetes API server from reaching istiod webhook.
```bash # List all network policies in istio-system kubectl get networkpolicies -n istio-system
# List network policies in affected namespace kubectl get networkpolicies -n production
# Check if policies block webhook traffic kubectl get networkpolicy -n istio-system -o yaml | grep -A20 ingress:
# API server traffic comes from control plane nodes # Policies need to allow traffic on port 15017
# If policies exist, check if they allow istiod webhook port: kubectl describe networkpolicy -n istio-system
# Create or update network policy to allow webhook traffic kubectl apply -f - <<EOF apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-istiod-webhook namespace: istio-system spec: podSelector: matchLabels: app: istiod policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 0.0.0.0/0 # Allow from API server (adjust based on your cluster) ports: - protocol: TCP port: 15017 - protocol: TCP port: 15012 - protocol: TCP port: 15014 EOF
# For GKE/EKS clusters, get API server IP range # GKE: Check VPC configuration # EKS: Check security groups
# Test webhook connectivity after fixing policies kubectl run test-webhook --image=curlimages/curl -it --rm --restart=Never -- curl -k https://istiod.istio-system.svc:15017/inject ```
Step 9: Restart Pods to Get Sidecar Injection
After fixing the configuration, recreate pods to trigger sidecar injection.
```bash # Restart deployments in affected namespace kubectl rollout restart deployment -n production
# Restart all deployments kubectl get deployments -n production -o name | xargs kubectl rollout restart -n production
# Restart statefulsets if any kubectl rollout restart statefulset -n production
# Wait for rollouts to complete kubectl rollout status deployment -n production --timeout=300s
# Check that pods now have 2 containers kubectl get pods -n production
# Should show READY 2/2
# Verify istio-proxy container exists kubectl get pod -n production -l app=frontend -o jsonpath='{.spec.containers[*].name}' # Should include: frontend istio-proxy
# Check pod annotations for injection confirmation kubectl get pod -n production -l app=frontend -o jsonpath='{.metadata.annotations}'
# Should show: # sidecar.istio.io/status: '{"version":"...","initContainers":["istio-init"],"containers":["istio-proxy"],...}'
# Verify sidecar container details kubectl describe pod -n production -l app=frontend | grep -A30 "istio-proxy"
# Check proxy status istioctl proxy-status
# Should show pods with SYNCED status ```
For pods managed by other controllers (CronJobs, Jobs, DaemonSets), you may need to trigger recreation differently.
Step 10: Verify Mesh Integration and Test Traffic
Confirm that pods are now properly integrated with the Istio mesh.
```bash # Run istioctl analyze to check for remaining issues istioctl analyze
# Should show no warnings about missing sidecars
# Check proxy status for all pods istioctl proxy-status
# All pods should show SYNCED status
# Test mTLS is working istioctl authn tls-check frontend.production.svc.cluster.local
# Should show mTLS enabled
# Check traffic is flowing through mesh # Deploy test pod and make requests kubectl run test-client --image=curlimages/curl -n production -- sleep 3600
kubectl exec test-client -n production -- curl -s http://frontend.production.svc.cluster.local:80
# Check Kiali for traffic graph # Traffic should appear in Kiali dashboard
# If Kiali is installed: kubectl port-forward -n istio-system svc/kiali 20001:20001 & # Open http://localhost:20001 in browser
# Check Envoy configuration on pod istioctl proxy-config endpoint frontend-abc123-xyz789.production -o json
# Check cluster configuration istioctl proxy-config cluster frontend-abc123-xyz789.production
# Verify VirtualService is applied istioctl proxy-config routes frontend-abc123-xyz789.production --name=http
# Test traffic routing kubectl exec test-client -n production -- curl -H "Host: frontend.example.com" http://frontend.production.svc.cluster.local
# Check metrics in Prometheus/Grafana kubectl port-forward -n istio-system svc/prometheus 9090:9090 & # Query: istio_requests_total
# Verify AuthorizationPolicy works kubectl apply -f - <<EOF apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: test-policy namespace: production spec: selector: matchLabels: app: frontend rules: - from: - source: principals: ["cluster.local/ns/production/sa/test-client"] EOF
# Test policy enforcement kubectl exec test-client -n production -- curl -s http://frontend.production.svc.cluster.local # Should work
kubectl run unauthorized --image=curlimages/curl -n production -- sleep 30 kubectl exec unauthorized -n production -- curl -s http://frontend.production.svc.cluster.local # Should be denied (403 or connection reset) ```
Checklist for Fixing Istio Sidecar Injection
| Step | Action | Command | Status |
|---|---|---|---|
| 1 | Identify pods missing sidecars | istioctl analyze | ☐ |
| 2 | Check namespace labels and pod annotations | kubectl get ns -l istio-injection=enabled | ☐ |
| 3 | Verify istiod and webhook are running | kubectl get pods -n istio-system -l app=istiod | ☐ |
| 4 | Check MutatingWebhookConfiguration | kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml | ☐ |
| 5 | Fix namespace labels | kubectl label ns production istio-injection=enabled | ☐ |
| 6 | Remove disabling annotations | kubectl patch deployment frontend --type=json -p='...' | ☐ |
| 7 | Fix webhook configuration | Regenerate CABundle or restart istiod | ☐ |
| 8 | Check network policies | kubectl get networkpolicies -n istio-system | ☐ |
| 9 | Restart pods to get injection | kubectl rollout restart deployment -n production | ☐ |
| 10 | Verify mesh integration | istioctl proxy-status, istioctl authn tls-check | ☐ |
Verify the Fix
After completing all steps, verify that Istio sidecar injection is working:
```bash # 1. Check all pods have sidecar kubectl get pods --all-namespaces -o wide # All mesh pods should show READY 2/2 (or more)
# 2. No missing sidecar warnings from istioctl istioctl analyze # Should show: "No issues found"
# 3. All proxies synced istioctl proxy-status # All pods should show SYNCED status
# 4. mTLS working between services istioctl authn tls-check frontend.production.svc.cluster.local # Should show mTLS enabled with certificates
# 5. Traffic visible in Kiali # Open Kiali dashboard and check graph shows traffic
# 6. Webhook responds to requests kubectl run test --image=curlimages/curl -it --rm -- curl -k https://istiod.istio-system.svc:15017/inject # Should return valid response
# 7. New pods get sidecar automatically kubectl run new-test-pod --image=nginx -n production kubectl get pod new-test-pod -n production # Should show READY 2/2
# 8. Verify Envoy proxy is running kubectl exec frontend-abc123-xyz789 -n production -c istio-proxy -- pilot-agent request GET stats # Should return Envoy statistics
# 9. Check metrics in Prometheus curl http://localhost:9090/api/v1/query?query=istio_requests_total # Should return metrics for mesh traffic
# 10. Verify traffic routing works kubectl exec test-client -n production -- curl -v http://frontend.production.svc.cluster.local # Traffic should be routed through mesh ```
Related Issues
- [Fix Istio Traffic Misrouting](/articles/fix-istio-traffic-misrouting) - Traffic not routing correctly through mesh
- [Fix Cilium Network Policy Not Enforcing](/articles/fix-cilium-network-policy-not-enforcing) - Cilium policy issues
- [Fix Envoy Buffer Overflow Error](/articles/fix-envoy-buffer-overflow-error) - Envoy proxy issues
- [Fix Envoy Cluster Configuration Error](/articles/fix-envoy-cluster-configuration-error) - Envoy cluster config problems
- [Fix Consul Service Registration Failed](/articles/fix-consul-service-registration-failed) - Consul mesh issues
- [Fix Kubernetes Namespace Terminating](/articles/fix-kubernetes-namespace-terminating) - Namespace stuck issues
- [Fix Prometheus Remote Write Failing](/articles/fix-prometheus-remote-write-failing) - Metrics collection issues