• Check if any other resources (PVCs, Secrets) exist before deleting.
• Use kubectl get all -n to inspect.
• Clean up empty namespaces to reduce clutter.

• Docs: Reference

• Define limits using ResourceQuota for pods, memory, and CPU.
• Helps avoid over-provisioning and noisy neighbor issues.
• Review quotas using kubectl describe quota -n .

• Docs: Reference

• LimitRanges define default and max values for CPU/memory.
• Prevents pods from using unlimited resources.
• Use kubectl create limitrange ... or kubectl describe limitrange -n .

• Docs: Reference

• Docs: Reference

• Run kubectl describe ds -n to check for scheduling issues.
• Check node taints and conditions.
• Ensure resource requests are not too high for nodes.

• Docs: Reference

• Run kubectl describe deployment -n to view status.
• Check for failed pods using kubectl get pods -n .
• Review rollout and events for delays or crashes.

• Docs: Reference

• Run kubectl describe sts name -n namespace to view rollout and events.
• Check pod logs and PersistentVolumeClaim bindings.
• Confirm storage class availability and node scheduling constraints.

• Docs: Reference

• Check if the target workload exists using kubectl get deploy|sts -n .
• Use kubectl describe hpa -n to inspect HPA status and events.
• Ensure metrics-server is running and the target exposes the required metrics.

• Docs: Reference

• Add resources.requests.cpu and resources.requests.memory to every container.
• Review both workload and initContainers with kubectl get deploy,statefulset,daemonset -A -o yaml.
• Apply any missing fields, then rerun KubeBuddy to confirm.

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Deployment spec.selector.matchLabels must match the Pod template metadata.labels.
• Services should have spec.selector that targets the same labels used by the Deployment and Pods.
• Use kubectl get deployment,svc,pod -o yaml to compare values and fix mismatches.

• Docs: Reference

• Add resources.requests.cpu and/or resources.requests.memory for HPA target containers.
• Use consistent requests across replicas to avoid unstable scaling behavior.
• After updates, validate HPA behavior with kubectl describe hpa.

• Docs: Reference

• If GitOps/Helm controls requests, consider VPA updateMode: Off or Initial.
• Avoid overlapping HPA (CPU/memory) and VPA ownership without clear boundaries.
• Document which controller owns requests per workload.

• Docs: Reference

• Ensure replicated workloads (2+ replicas) have a matching PDB.
• Avoid minAvailable equal to replica count for normal maintenance windows.
• Use pragmatic budgets (for example maxUnavailable: 1 for many workloads).

• Docs: Reference

• Investigate container logs and termination reasons for recurring restarts.
• Increase memory requests/limits when OOMKilled events are observed.
• Apply sizing changes gradually and validate SLO/error rates.

• Docs: Reference

• Add resources.limits.memory to every application and init container.
• Set the limit high enough for normal peaks, then tune requests separately.
• Review workloads with kubectl get deploy,statefulset,daemonset -A -o yaml to confirm the source manifests carry the limit.

• Docs: Reference

• Add topologySpreadConstraints or affinity.podAntiAffinity to each workload with multiple replicas.
• Prefer distribution across nodes and zones using stable labels such as topology.kubernetes.io/zone and kubernetes.io/hostname.
• Update the source Deployment, StatefulSet, or Helm values so the spreading rule is maintained on future releases.

• Docs: Reference

• Use kubectl logs -n to view logs and identify crash causes.
• Run kubectl describe pod -n to check events and probe failures.
• Verify readiness and liveness probes are configured properly.
• Check for missing config, secrets, or volume mounts.
• Adjust resource requests/limits to avoid OOM kills.

• Docs: Reference

• Pods with extended uptime may indicate skipped rolling updates.
• Use kubectl rollout status to inspect deployment progress.
• Restart pods when config changes are missed or memory use drifts.
• Check if the workload is intended to be static or ephemeral.

• Docs: Reference

• Check the pod events with kubectl describe pod <pod> -n <ns>
• Review logs using kubectl logs <pod> -n <ns>
• Validate container specs, resource limits, and init containers
• Check node availability or taints

• Docs: Reference

• Run kubectl describe pod <pod> -n <namespace> to check scheduling events
• Check if nodes meet the pod's resource requests and tolerations
• Look for unresolved PVCs, Secrets, or ConfigMaps
• Check cluster-wide CPU and memory availability

• Docs: Reference

• Run kubectl logs <pod-name> -n <namespace> to see error output
• Describe the pod for events and messages: kubectl describe pod <pod> -n <ns>
• Check init containers, config errors, and resource limits

• Docs: Reference

• Run kubectl delete pod -n to remove them
• Ensure automation or users clean up after using kubectl debug

• Docs: Reference

🛠️ Use Specific Image Tags

• Don't use the :latest tag or leave the image tag blank.
• Why: It can pull different images on each deploy, leading to drift.
• Fix: Tag images explicitly (e.g., :v1.2.3) and update the pod spec.
• Docs: Kubernetes Image Tagging

• Docs: Reference

🛠️ Disable Automounting API Credentials

• Add automountServiceAccountToken: false to the Pod's spec.
• Edit with kubectl edit pod -n .
• Verify if the application needs API access (e.g., for controllers).
• Use RBAC to limit ServiceAccount permissions if access is required.

• Docs: Reference

🛠️ Investigate High CPU Pods

• Use kubectl top pod to see real-time CPU usage.
• Review app code or HPA settings for misbehaving containers.
• Consider raising CPU requests/limits or scaling out.

• Docs: Reference

🛠️ Investigate High Memory Pods

• Use kubectl top pod to review memory usage.
• Adjust resources.limits.memory appropriately.

• Docs: Reference

🛠️ Investigate Network Receive Rate

• Use kubectl top pod or Prometheus UI.
• Inspect service ingress patterns.

• Docs: Reference

Pod Sizing Guidance

• Set CPU and memory requests from p95 usage with safety headroom.
• Default CPU limits recommendation is none to avoid unnecessary CPU throttling and latency spikes.
• Keep memory limits set above memory request to control OOM blast radius.
• Validate against SLOs and roll out gradually.

• Docs: Reference

• Check pod status for the job using kubectl describe job .
• Verify resources and restart policies.
• Check logs with kubectl logs job/.

• Docs: Reference

• Inspect job with kubectl describe job .
• Check logs for errors using kubectl logs job/.
• Review pod events and resource limits.

• Docs: Reference

🔍 Services Without Endpoints

• Verify that your service has a valid selector.
• Check if pods exist and are ready in the same namespace.
• Use kubectl describe svc <name> and kubectl get endpointslices -n <namespace> -l kubernetes.io/service-name=<name>.
• Restart affected pods or fix labels as needed.

• Docs: Reference

🌐 Secure Exposed Services

• Use internal IP ranges or private LoadBalancers where possible.
• Restrict NodePort usage or protect with firewall rules.
• Disable external exposure for internal-only services.
• Consider network policies or service mesh for access control.

• Docs: Reference

🌐 Ingress Health Remediation

• Add spec.ingressClassName or annotations if missing.
• Validate all backend services and ports exist.
• Fix missing TLS secrets or use valid ones.
• Avoid duplicate host/path combinations.
• Use only valid pathTypes: Exact, Prefix, or ImplementationSpecific.

• Docs: Reference

• Docs: Reference

🚫 Resolve Ingress Conflicts

• Ensure that each unique host and path combination is defined in only one Ingress resource.
• Use specific hostnames instead of broad wildcards where possible to prevent unintended conflicts.
• Review your Ingress definitions for overlapping rules and consolidate or adjust as necessary.
• Test routing after making changes to confirm correct behavior.

• Docs: Reference

⭐ Review Wildcard Ingresses

• Evaluate if a wildcard host is truly necessary for the application's routing requirements.
• Where possible, replace wildcards with specific hostnames to limit unintentional exposure.
• Ensure that security policies and firewalls are in place to control access to wildcard-enabled Ingresses.

• Docs: Reference

🎯 Fix Service TargetPort Mismatches

• Verify the targetPort in your Service definition. It should either be a numerical port or a named port.
• Check the containerPorts in the Pods selected by the Service.
• Ensure the `targetPort` (by number) or `name` (for named ports) in the Pod's `containerPort` matches the Service's `targetPort`.
• A common fix is to ensure consistent naming conventions or directly use port numbers.

• Docs: Reference

🔄 Review ExternalName to Internal IP

• ExternalName services are primarily for CNAME-like redirection to external DNS names.
• If routing to an internal IP address, consider if a standard `Service` with manually created `EndpointSlice` or a `Service` with `type: ClusterIP` backed by pods is more appropriate.
• Ensure this configuration is intentional and does not bypass intended network segmentation or security policies.

• Docs: Reference

🔐 Restrict Overly Permissive Network Policies

• Ensure `policyTypes` are paired with explicit `ingress` and `egress` rules that define allowed traffic.
• Avoid empty `ingress` or `egress` sections if the `policyTypes` are defined, as this defaults to allowing all traffic for that type.
• Limit the use of `ipBlock: 0.0.0.0/0`. Instead, define specific CIDR ranges for necessary external communication.
• Adopt a "deny-by-default" approach and explicitly allow only required communication.

• Docs: Reference

🚫 Restrict '0.0.0.0/0' in Network Policies

• Avoid using `ipBlock: 0.0.0.0/0` in NetworkPolicies unless absolutely required for specific, well-understood use cases (e.g., public internet access).
• Identify the precise CIDR ranges or specific IP addresses that need to be allowed.
• For egress, if public internet access is needed, consider egress gateways or more restrictive network policies to control outbound traffic.
• This is a critical security vulnerability if unintended.

• Docs: Reference

📝 Define Network PolicyTypes

• Always explicitly define `policyTypes` in your NetworkPolicy, such as `policyTypes: [Ingress]` or `policyTypes: [Ingress, Egress]`.
• This clearly indicates whether the policy applies to inbound, outbound, or both types of traffic.
• It prevents reliance on default behaviors, which can vary or change between Kubernetes versions or CNI implementations.

• Docs: Reference

⚠️ Avoid HostNetwork Usage

• Using `hostNetwork: true` is a security risk as it grants the pod direct access to the node's network stack.
• This bypasses many Kubernetes network security features and network policies.
• Only use `hostNetwork` for specific, highly privileged use cases (e.g., CNI plugins, network observability tools) and limit access via RBAC and Pod Security Standards.
• For typical applications, rely on ClusterIP, NodePort, or LoadBalancer services for exposure.

• Docs: Reference

🚦 Begin Gateway API Migration

• Create or select a GatewayClass supported by your controller.
• Define one or more Gateway resources for north-south traffic entry.
• Migrate Ingress rules incrementally to HTTPRoute and validate behavior.
• Run both models in parallel during transition where supported.

• Docs: Reference

🧭 Fix HTTPRoute Parent Binding

• Set spec.parentRefs to an existing Gateway.
• Check route status conditions and Gateway listener compatibility.
• Verify namespace permissions and allowedRoutes policy.

• Docs: Reference

🧹 Clean Up or Attach Routes

• Attach one or more HTTPRoute resources to each active Gateway.
• Delete unused Gateways to avoid confusion and stale entry points.
• Confirm listener and route host/path alignment.

• Docs: Reference

🚦 Validate Gateway Readiness

• Check GatewayClass and Gateway status.conditions for Accepted and Programmed.
• Verify the Gateway controller deployment is healthy and watching the relevant classes.
• Fix listener, address, or controller configuration issues before cutover.

• Docs: Reference

🔐 Fix Gateway TLS References

• Verify each certificateRef points to an existing Secret.
• For cross-namespace refs, create a ReferenceGrant in the Secret namespace.
• Re-check Gateway listener status after grant/secret updates.

• Docs: Reference

🎯 Use Unique Service Selectors

• Review Services in the same namespace that select the exact same pod label set.
• Split selectors so each Service represents a distinct routing contract, or consolidate duplicate Services where appropriate.
• Update the source manifest or Helm chart so the selector change persists across releases.

• Docs: Reference

🗑️ Clean Up Orphaned PVs

• Audit: Verify the PV is truly unneeded using kubectl describe pv <name>.
• Delete: Remove unneeded PVs with kubectl delete pv <name>.
• Caution: Ensure no future PVC will bind to it before deletion.

• Docs: Reference

💾 Clean Up Unused PVCs

• Audit: Confirm PVC is not needed using kubectl describe pvc -n .
• Delete: Remove PVCs no longer required with kubectl delete pvc .
• Prevent: Automate cleanup for stale environments or ephemeral workloads.

• Docs: Reference

✍️ Specify StorageClass for PVCs

• Edit: Add storageClassName: <your-storage-class-name> to the PVC spec.
• Consistency: Ensure consistent storage provisioning across environments.
• Awareness: Understand which StorageClass is truly being used.

• Docs: Reference

⚠️ Review ReadWriteMany PVCs

• Verify: Confirm if the storage backend truly supports concurrent writes.
• Adjust: If not, change PVC access mode to ReadWriteOnce.
• Migrate: For shared data, use appropriate shared file storage solutions.

• Docs: Reference

🚫 Troubleshoot Unbound PVCs

• Describe PVC: Use kubectl describe pvc <name> -n <namespace> to see events and reasons for Pending.
• Check StorageClass: Ensure the specified StorageClass exists and is correctly configured.
• Review Provisioner: Verify the storage provisioner is running and healthy.

• Docs: Reference

🔄 Migrate Deprecated StorageClasses

• Identify: Pinpoint PVCs using the deprecated StorageClass.
• Create: Define a new StorageClass with the appropriate CSI driver.
• Migrate: Follow the migration path for your specific storage provider to move data.

• Docs: Reference

🔄 Migrate Azure StorageClasses to CSI

• Create replacement StorageClasses that use disk.csi.azure.com or file.csi.azure.com.
• Move PVCs and workloads off the in-tree StorageClass before migrating to AKS Automatic.
• Validate reclaim policies, SKU, and mount options during the migration.

• Docs: Reference

📊 Manage Storage Consumption

• Identify: Use monitoring tools to find namespaces/pods consuming the most storage.
• Clean Up: Delete old data, snapshots, or unused PVCs/PVs.
• Scale: Plan for increasing storage capacity or optimizing storage allocation.

• Docs: Reference

📈 Enable Volume Expansion

• Assess: Determine if your applications need dynamic volume resizing.
• Configure: Add or set allowVolumeExpansion: true in the StorageClass definition.
• Backend Check: Ensure your storage backend supports online volume expansion.

• Docs: Reference

🛠️ Clean Up Orphaned ConfigMaps

• Verify: Check usage (kubectl describe cm ).
• Delete: kubectl delete cm if unused.
• Automation: Schedule periodic scans.

• Docs: Reference

🛠️ Fix Duplicate ConfigMap Names

• Standardize: Use unique names or a naming convention that includes the environment or team name.
• Audit: Periodically review ConfigMaps across namespaces for duplication.
• Automation: Use policies or linting tools to catch duplicates pre-deploy.

• Docs: Reference

🛠️ Reduce ConfigMap Size

• Refactor: Move large files or data to PersistentVolumes.
• Split: Break up oversized ConfigMaps into smaller ones by function.
• Review: Check for secrets or binary blobs mistakenly stored in ConfigMaps.

• Docs: Reference

🛠️ Investigate API Server Latency

• Check kube-apiserver logs.
• Review etcd performance.

• Docs: Reference

🔐 RBAC Misconfiguration Fixes

• Don't leave roleRef blank in bindings.
• Use valid Roles/ClusterRoles that exist in the correct namespace.
• Verify ServiceAccounts exist in the namespace specified.
• Remove or correct subjects pointing to non-existent namespaces.

• Docs: Reference

🔐 RBAC Hardening Tips

• Avoid using cluster-admin directly in bindings.
• Don’t assign Roles or ClusterRoles with wildcard verbs/resources/apiGroups.
• Restrict access to sensitive resources like secrets or pods/exec.
• Minimize privileges for default ServiceAccounts.
• Document use of any built-in roles used in production.

• Docs: Reference

🧾 Remove Orphaned ServiceAccounts

• Audit ServiceAccounts not referenced in RoleBindings, ClusterRoleBindings, or used by Pods.
• Delete those not actively used to reduce attack surface.
• Consider automating SA cleanup with CI/CD or policy enforcement.

• Docs: Reference

🗂️ Clean up Unused or Ineffective RBAC

• Remove RoleBindings or ClusterRoleBindings without subjects.
• Prune Roles and ClusterRoles not referenced by any bindings.
• Remove roles with no defined rules unless planned for future use.

• Docs: Reference

🔐 Orphaned Secrets Cleanup

• Remove Secrets not referenced in Pods, Deployments, StatefulSets, or Ingresses.
• Audit Secret content before deletion to avoid removing active credentials.
• Validate Custom Resources don’t indirectly depend on these Secrets.
• Regularly prune Secrets as part of security hygiene.

• Docs: Reference

Avoid Host-Level Sharing

• Set hostPID: false and hostNetwork: false unless needed for special workloads.
• Review security implications of namespace sharing with the host.
• Restrict use of these settings to trusted namespaces and workloads.
• Consider using PSPs or OPA/Gatekeeper policies to prevent usage cluster-wide.

• Docs: Reference

RunAsUser Hardening

• Set runAsUser to a non-zero UID at pod or container level.
• Avoid relying on container defaults and define securityContext explicitly.
• Validate any custom base images that may default to root.

• Docs: Reference

Disable Privileged Containers

• Remove securityContext.privileged: true from container specs.
• Refactor workloads to avoid needing host-level access.
• Enforce restrictions using Pod Security Policies or OPA/Gatekeeper.
• Limit use to dedicated namespaces with strict controls.

• Docs: Reference

🔒 Disable hostIPC for Pods

• Remove hostIPC: true from pod specs.
• Review workloads that require inter-process communication with the host.
• Use shared memory only through secure, scoped means.

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

Disable Automounting in ServiceAccounts

• Add automountServiceAccountToken: false to the ServiceAccount spec.
• Edit with kubectl edit serviceaccount <sa-name> -n <namespace>.
• Ensure Pods needing API access override this in their spec with automountServiceAccountToken: true.
• Use RBAC to limit ServiceAccount permissions if access is required.

• Docs: Reference

• Docs: Reference

• Set securityContext.seccompProfile.type: RuntimeDefault for the pod or each container.
• If you need a custom profile, use Localhost and ensure the profile exists on the node.
• Doing this avoids AKS Automatic seccomp warnings and makes the security posture explicit.

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Docs: Reference

• Group similar warnings to spot patterns.
• Use kubectl describe and logs to investigate.

• Docs: Reference

• Use kubectl describe to get full context.
• Check logs for root cause.

• Docs: Reference