01 · The basics
What is Kubernetes?
Kubernetes is an open-source platform that manages the operation of containerised applications. It distributes workloads across available machines, supports updates and scaling, and works towards the desired state you have defined.
This desired state specifies, for example, which container image an application uses and how many instances should run. Kubernetes compares the actual state with that definition. If a managed Pod fails, controllers can create a replacement. The application itself still needs to be configured appropriately.
An example: You define three instances of a web service. A Deployment manages their rollout; a Service provides stable network access to the matching Pods. You describe an update as a new desired state.
The abbreviation k8s stands for the same name: there are eight letters between “K” and “s”. A Kubernetes cluster is the combined operating environment of the control plane and nodes.
How do Docker and Kubernetes fit together?
Container images package an application with its runtime dependencies. Tools such as Docker help you build and run these containers locally. Kubernetes orchestrates workloads in the cluster. A compatible container runtime, such as containerd, runs the containers on the nodes. A Kubernetes cluster does not require Docker Engine for this.
Technical background: Kubernetes overview and containers and container runtimes.
02 · Making the decision
When is Kubernetes worth using?
Kubernetes becomes useful when you want to standardise recurring operational tasks for several containerised workloads. Your requirements and your team's operational expertise are the deciding factors.
Consider Kubernetes
Multiple services, frequent changes
-
Services need to be deployed and scaled independently.
-
Deployments need to be defined reproducibly.
-
Multiple teams need a shared platform with controlled access permissions.
-
You want to use automated rollouts and reconciliation with the desired state.
Consider a simpler setup
A manageable application, limited operations
-
A single application runs with a stable workload.
-
A VM or a small container host already meets the requirements.
-
The team wants to take on as little platform configuration as possible.
-
The additional Kubernetes components would make operations more complex.
Typical use cases include microservices, SaaS applications, and automated deployment processes. Data processing and AI workloads are also possible, but require suitable resources and components. Suitability for a particular workload depends on its requirements.
Which responsibilities remain despite using Kubernetes?
Applications still need access controls, appropriate resources, monitoring, and an approach to persistent data. Automatic scaling requires the relevant configuration and available capacity. Kubernetes alone does not provide a complete backup, logging, or security solution either.
Our comparison of Managed App Platform, VMs, and Kubernetes provides guidance on different operating models.
03 · Architecture and components
How does a Kubernetes cluster work?
The control plane manages the cluster state. Applications run in Pods on the worker nodes. You communicate with the cluster through the Kubernetes API, for example using the kubectl command-line tool.
ContainerPod
Container
ContainerPod
Container
Example with two worker nodes. The actual number and distribution depend on your environment.
Which component does what?
API server: The interface for requests to the cluster. Tools and cluster components work through the Kubernetes API.
etcd: Stores the control plane's data. This cluster state is different from your application's data.
Scheduler: Assigns Pods that have not yet been scheduled to suitable nodes. It considers resource requirements and constraints, among other factors.
Controllers: Observe resources and make changes to reconcile the actual state with the desired state.
Worker node: Provides the runtime environment for Pods. The kubelet and container runtime handle their execution on the node.
Pods, Deployments, and Services: the key terms
Pod: The smallest deployable unit. A Pod contains one or more closely related containers.
Deployment: Describes a desired state for Pods and manages their rollout through ReplicaSets. It is typically used for stateless applications.
Service: Provides stable network access to a group of Pods. A Service does not automatically make an application accessible from the internet; that depends on the Service type and the environment.
Namespace: Groups many cluster resources under a shared name, for example for projects or teams. A Namespace alone is not a complete security boundary.
ConfigMap: Keeps non-confidential configuration separate from the container image.
Secret: Holds confidential values such as credentials. Base64 encoding is not encryption; access permissions and protection of stored data also need to be considered.
Deployment → ReplicaSet → Pods with containers
This chain describes how an application is managed. The Service belongs to the networking side: it provides access to the matching Pods, rather than requiring their changing addresses to be stored directly in other applications.
04 · Responsibilities
Managed Kubernetes or a self-managed cluster?
With a self-managed cluster, your team provisions and operates the cluster components. With Managed Kubernetes, a provider takes on certain platform responsibilities, often including operation of the control plane. Exactly which responsibilities are included depends on the service and the contract. How the offerings in Germany compare is shown in our managed Kubernetes provider comparison.
| Task | Self-managed cluster | Managed Kubernetes |
|---|---|---|
| Control plane | Your team provisions, operates, and updates it. | Often operated by the provider. Check the scope and update policies. |
| Worker nodes | Your team plans capacity, runtime, and maintenance. | Provisioning and maintenance depend on the scope of the service. |
| Applications | Your team maintains images, configuration, and deployments. | Usually remain your team's responsibility unless additional application operations have been agreed. |
| Data and recovery | Your team plans backups and recovery. | Explicitly clarify coverage for cluster state, volumes, and the application. |
| Access and observability | Your team organises access, metrics, and alerting. | Distinguish platform services from responsibility for your workloads. |
The table describes operating models in general. It is not a guaranteed service matrix for centron.
Clarify before choosing: Who updates which components? Who responds to incidents? Which data is backed up? Which monitoring data and alerts are included? This helps you assess the work that remains for your own team.
05 · Your learning path
How do I get started in practice?
Choose your environment first. The guides then take you from cluster management and a first application to configuration, resources, and monitoring. A branch at the end leads to CI/CD and GitOps.
Option A · Practice environment
Start with Minikube on your own computer
Want to explore the basic concepts? Minikube provides a local Kubernetes environment. You need a suitable computer and the prerequisites for your chosen driver.
Start local Kubernetes development with Minikube →
The tutorial covers getting started locally. You can also find current installation instructions and system requirements in the official Minikube documentation.
Option B · Existing environment
Connect to an existing cluster
Already have access to a Kubernetes cluster? Have its kubeconfig and the required permissions ready. For the centron platform, the documentation guides you through the first steps and connecting with kubectl.
Read the first steps in the centron documentation →
Use a suitable test environment for exercises and check the selected cluster context before making changes.
Manage the cluster with kubectl
Set up kubectl, check the connection, and get to know nodes, Pods, Deployments, and Services.
Prerequisite: a reachable cluster and valid access configuration.
Deploy an application
Learn how to install and configure applications with Helm. This gives you practical experience with the Kubernetes resources from the architecture overview.
Prerequisite: cluster access and the permissions and resources required for the application.
Separate confidential configuration
Create Secrets and use them in Pods. This keeps credentials separate from the application image and helps you understand the limitations of this mechanism.
Prerequisite: kubectl and permissions in the selected Namespace.
Allocate resources deliberately
Understand requests and limits and control the resources used by Pods. You will also learn about policies for Namespaces.
Prerequisite: the ability to edit Pod or Deployment configuration.
Set up metrics and monitoring
Build a monitoring environment with kube-prometheus-stack and explore cluster and workload metrics.
Prerequisite: Helm, appropriate cluster permissions, and capacity as specified in the tutorial.
Already using GitLab? Once you are familiar with the basics, two guides take you from the pipeline into the cluster. The GitLab Runner tutorial shows how CI jobs run as Pods on Kubernetes. With the Flux CD tutorial, you then roll out applications from a GitLab project by Git commit: Flux reads the desired state from the repository and reconciles the cluster with it at fixed intervals. You also need access to GitLab for both steps, and cluster admin rights for Flux.
06 · Further topics
Which topics matter for ongoing operations?
Explore the components your application actually needs. The basics explain their role; the linked guides cover implementation.
Persistent data · Docs
Storage with Persistent Volume Claims
A PVC requests persistent storage. The documentation explains how to use it on the centron platform.
Networking · Tutorial
Control communication with NetworkPolicies
Restrict network access between workloads and investigate it with Cilium and Hubble. The guide requires these components.
Automation · Overview
Understand CI/CD and GitOps
CI builds and checks changes; CD organises deployment. With GitOps, a version-controlled description forms the basis of the desired state. A GitOps tool such as Flux CD or Argo CD compares the cluster with this state in Git and reconciles any differences.
Look up · Reference
Keep kubectl commands to hand
Know the basics and need a particular command? The reference complements the learning path in your day-to-day work.
What is a Kubernetes Operator?
An Operator combines custom resource types with a controller to automate application-specific operational tasks. It can help manage a database, for example. The tasks it handles depend on the particular Operator; updates and recovery need to fit your application.
07 · Kubernetes at centron
Kubernetes at centron
centron offers Managed Kubernetes and operates the control plane according to the product description. The documented features and the agreed scope of service determine how you can use it for your applications.
Use the product page for an overview of the offering, the pricing page for plans and options, and the documentation for setup and technical tasks. Before production use, clarify responsibility for worker nodes, updates, monitoring, and backups.
From an overview to the right environment
Want to use Kubernetes? Explore the offering or discuss your requirements with centron.
Explore Managed Kubernetes → Plans and options →08 · Frequently asked questions
Frequently asked questions about Kubernetes
Do I need multiple servers for Kubernetes?
For learning, a local environment on one computer can be sufficient. A Kubernetes cluster has a control plane and at least one worker node; in local environments, these roles can share the same machine. For production operations, the architecture depends on capacity and availability requirements.
When is Docker on a VM enough?
If a manageable application with a few containers on one host meets your requirements, this can be a suitable operating model. Assess updates, recovery, and failure behaviour. Kubernetes becomes useful when additional orchestration tasks justify its overhead.
Does Kubernetes automatically make my application highly available?
No. Kubernetes can provide replacement Pods and manage multiple instances. However, availability also depends on the application, resources, distribution across nodes, networking, storage, and other dependencies. A cluster alone does not eliminate these failure risks.
Which tasks remain my responsibility with Managed Kubernetes?
Images, application configuration, deployments, and application-specific access permissions usually remain your team's responsibility. For nodes, updates, monitoring, and backups, the agreed scope of service determines the division of responsibilities. Additional application operations must be explicitly agreed.
Can I easily move applications between providers?
The Kubernetes API provides a common foundation. However, provider-specific storage classes, network services, identity integrations, and external services may still require changes. Check these dependencies and data transfer requirements before switching.
How do I get changes into the cluster via Git?
With a GitOps tool such as Flux CD or Argo CD. Both use a Git repository as the source of the desired state; changes are then made as commits rather than as direct kubectl commands. Flux checks the repository at fixed intervals. If someone changes managed objects directly in the cluster, Flux resets them to the state in Git at the next reconciliation. Our Flux CD tutorial shows how this works with GitLab and how Flux and Argo CD differ.
09 · Sources and documentation
Sources and documentation
The technical explanations are based on the Kubernetes documentation and, for GitOps, also on OpenGitOps and the Flux and Argo CD documentation. Statements about the offering refer to the linked centron product description. Sources checked: 7 October 2026; GitOps additions: 9 October 2026.