Kubernetes won. The question in 2020 isn’t whether to use it—it’s how to use it effectively. As the ecosystem matures, priorities shift from basic functionality to operational excellence.
Here’s what matters for Kubernetes in 2020.
The Maturity Shift
From Adoption to Operations
The conversation has changed:
2018-2019: “Should we use Kubernetes?” 2020: “How do we run Kubernetes well?”
Organizations have moved past proof-of-concepts. Production clusters exist. Now comes the hard part: operating them reliably, securely, and efficiently.
Managed Kubernetes Dominance
Running your own control plane requires justification:
Decision tree:
├── Do you need custom control plane modifications?
│ └── No → Use managed (EKS, GKE, AKS)
├── Do you have the team to maintain it?
│ └── No → Use managed
├── Are you in a regulated environment with specific requirements?
│ └── Check if managed meets them (usually yes)
└── Default → Use managed
Self-managed Kubernetes will become the exception, not the rule.
Security as Priority
Beyond Basic Security
Basic security is now table stakes:
- RBAC configured properly
- Pod security policies/standards
- Network policies
- Image scanning in CI/CD
The focus shifts to:
- Runtime security and threat detection
- Supply chain security
- Secrets management maturity
- Zero trust networking
Policy as Code
Open Policy Agent and Gatekeeper will become standard:
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: require-team-label
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Namespace"]
parameters:
labels: ["team", "cost-center"]
Every cluster will need:
- Admission control
- Compliance as code
- Automated policy enforcement
GitOps Goes Mainstream
Declarative Operations
GitOps moves from early adopter to mainstream:
Git Repository (Source of Truth)
│
▼
┌───────────────┐
│ Argo CD │
│ or Flux │
└───────────────┘
│
▼
Kubernetes Cluster
Benefits driving adoption:
- Audit trail for all changes
- Easy rollback (git revert)
- Pull-based deployments (more secure)
- Consistency across environments
Multi-Cluster GitOps
As organizations run multiple clusters, managing them consistently becomes critical:
# ApplicationSet for multi-cluster
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: api-service
spec:
generators:
- clusters:
selector:
matchLabels:
environment: production
template:
spec:
project: default
source:
repoURL: https://github.com/company/apps
path: services/api
Observability Investment
Beyond Basic Monitoring
Prometheus and Grafana are starting points. Mature observability requires:
Distributed tracing:
- Jaeger/Zipkin integration
- Auto-instrumentation with service mesh
- Trace-based alerting
Log aggregation:
- Structured logging standard
- Correlation with traces
- Cost-effective retention
Metrics refinement:
- Custom metrics for business logic
- SLO-based alerting
- Capacity planning from metrics
Cost Observability
FinOps for Kubernetes becomes essential:
# Tracking costs per team/service
labels:
team: orders
service: api
cost-center: engineering
Tools like Kubecost will become standard infrastructure.
Developer Experience Focus
Platform Engineering
Platform teams emerge to make Kubernetes accessible:
┌─────────────────────────────────────────────┐
│ Developer Experience │
│ ┌────────────────────────────────────────┐ │
│ │ Self-Service Portal / CLI │ │
│ │ - Create namespace │ │
│ │ - Deploy application │ │
│ │ - Configure resources │ │
│ └────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────┐ │
│ │ Platform Components │ │
│ │ - Ingress, Service Mesh │ │
│ │ - Observability, Security │ │
│ │ - CI/CD, GitOps │ │
│ └────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────┐ │
│ │ Kubernetes │ │
│ └────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
Developers shouldn’t need to be Kubernetes experts.
Abstractions Layer
Higher-level abstractions will gain traction:
- Crossplane for infrastructure
- KubeVela for applications
- Internal developer platforms
The goal: hide Kubernetes complexity while preserving its power.
Service Mesh Reality Check
Adoption Will Be Selective
Service mesh provides value but at a cost:
- ~50MB memory per sidecar
- ~10ms latency per hop
- Operational complexity
Organizations will be more selective:
- Critical services: yes to mesh
- Simple internal services: maybe not
- Batch jobs: probably not
Sidecar Alternatives
eBPF-based approaches (Cilium) will gain attention:
- No sidecar overhead
- Kernel-level networking
- Performance advantages
The sidecar model isn’t dead, but alternatives will emerge.
Stateful Workloads
Databases on Kubernetes
Operators make stateful workloads practical:
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: production-db
spec:
instances: 3
postgresql:
parameters:
max_connections: "200"
storage:
size: 100Gi
storageClass: fast-ssd
Running databases on Kubernetes will become more common, though not universal.
Operator Maturity
More production-ready operators:
- PostgreSQL (CloudNativePG, Zalando)
- MySQL (Oracle, Vitess)
- Kafka (Strimzi)
- Elasticsearch (ECK)
What To Focus On
For Organizations Starting
- Use managed Kubernetes
- Start with stateless workloads
- Invest in observability early
- Adopt GitOps from day one
- Focus on developer experience
For Mature Organizations
- Security automation and policy
- Multi-cluster management
- Cost optimization
- Service mesh for critical paths
- Operator development for custom needs
Predictions Summary
Will happen:
- Managed Kubernetes becomes default
- GitOps goes mainstream
- Security automation becomes standard
- Platform engineering emerges as discipline
Might happen:
- Service mesh reaches mass adoption
- eBPF changes networking model
- Stateful workloads become common
Won’t happen (yet):
- Everyone running self-managed
- Service mesh everywhere
- Kubernetes becoming “simple”
Key Takeaways
- 2020 is about operational excellence, not adoption
- Managed Kubernetes is the default choice; justify self-managed
- Security automation and policy as code become mandatory
- GitOps moves from early adopter to mainstream
- Observability investment must deepen beyond basic monitoring
- Platform engineering abstracts Kubernetes complexity from developers
- Service mesh adoption will be selective, not universal
- Stateful workloads become more viable with mature operators
Kubernetes maturity means the focus shifts from “making it work” to “making it work well.” That’s harder but more valuable.