When an on-demand service becomes expensive or needs dependable uptime, Kubernetes provides a container-orchestration path between running containers directly and managing infrastructure yourself. Teams submit containerized workloads to a cluster instead of maintaining every server and load balancer by hand. section 10.0 section 10.1
Kubernetes turns infrastructure concerns into resource abstractions. Deployments manage groups of containers called pods, services route calls to those deployments, and the cluster can shift workloads as demand changes. section 10.1 section 10.8
A practical Kubernetes rollout follows this shape:
- Create or use a Kubernetes cluster for the team’s containerized applications. section 10.0
- Define deployments that run application containers and scale them for demand or availability. section 10.8
- Expose deployments through services that route application calls and support load balancing. section 10.1
- Provide application settings through secrets and configuration files populated into environment variables. section 10.8
From translation service to shared cluster
A translation service initially runs on demand, but rising usage makes dedicated capacity attractive. The team creates a Kubernetes cluster, deploys the API, deploys its database with Helm, and configures the API to use that database. The same cluster can host other teams’ containers, improving resource use while Kubernetes handles restarts, scaling, and traffic routing. section 10.0 section 10.1
Use the deployment-stack figure to place Kubernetes between container-as-a-service and infrastructure-as-a-service approaches, with the container treated as the shippable product. section 10.1
