Container orchestration with Kubernetes has become the de facto standard for deploying and managing modern applications. During M&A due diligence, the maturity and quality of a target company's container and Kubernetes environment can reveal significant insights about operational capability, technical debt, and future scalability. A thorough assessment requires evaluating cluster architecture, workload configuration, security posture, and operational practices.
Cluster Architecture and Configuration
Start by understanding the Kubernetes cluster topology. How many clusters are in operation, and how are they distributed across environments such as development, staging, and production? Evaluate whether the company uses managed Kubernetes services like EKS, AKS, or GKE, or operates self-managed clusters. Self-managed clusters require significantly more operational expertise and carry higher maintenance overhead.
Assess the cluster sizing and resource allocation strategy. Are nodes right-sized for the workloads they run, or is there significant over-provisioning or under-provisioning? Evaluate the use of node pools, auto-scaling configurations, and resource quotas. Poorly configured clusters can waste significant cloud spend or create performance bottlenecks during peak demand.
Networking configuration within Kubernetes clusters is a frequent source of complexity and risk. Evaluate the CNI plugin in use, network policies, service mesh implementations, and ingress configurations. Determine whether network segmentation is properly implemented to isolate sensitive workloads.
Workload Configuration and Best Practices
Review the Kubernetes manifests and Helm charts used to deploy workloads. Assess whether resource requests and limits are properly defined for all containers, whether health checks and readiness probes are configured, and whether pod disruption budgets are in place for critical services.
Container image management is a critical area. Evaluate the container registry in use, image scanning practices, and base image update policies. Determine whether images are built from minimal base images, whether they run as non-root users, and whether image tags are immutable. Running containers with the latest tag or with root privileges indicates immature security practices.
Security and Compliance
Kubernetes security is multi-layered and requires attention to cluster-level controls, namespace isolation, pod security standards, and network policies. Evaluate whether role-based access control (RBAC) is properly configured, whether pod security admission controllers are enforced, and whether secrets management uses external solutions like HashiCorp Vault rather than native Kubernetes secrets.
Supply chain security for container images has become increasingly important. Assess whether the company implements image signing and verification, software bill of materials (SBOM) generation, and vulnerability scanning in the CI/CD pipeline. Container supply chain attacks have become a significant threat vector that must be addressed.
Audit logging and compliance monitoring should be evaluated. Determine whether Kubernetes audit logs are collected and analyzed, whether compliance policies are enforced through policy engines like OPA Gatekeeper or Kyverno, and whether regular security assessments are performed against benchmarks like the CIS Kubernetes Benchmark.
Operational Maturity and Disaster Recovery
Assess the operational maturity of the Kubernetes environment by examining deployment frequency, change failure rate, mean time to recovery, and incident response procedures. Evaluate whether GitOps practices are in place for declarative infrastructure management and whether all cluster configurations are version-controlled.
Disaster recovery for Kubernetes environments requires backing up not only application data but also cluster state, including custom resource definitions, RBAC configurations, and persistent volume data. Evaluate the backup strategy, test the restoration procedures, and determine the recovery time and recovery point objectives. Organizations that have never tested their Kubernetes disaster recovery procedures are at significant risk of extended outages.