CONTAINERS / KUBERNETES
Consider Kubernetes when operating multiple containers, services and releases. A useful cluster plan covers application definitions, CPU and memory requests, network access, persistent data and operating responsibilities. The goal is to make changes manageable, beyond simply running containers.
01 / Overview
Kubernetes provides an orchestration approach for defining, scheduling and connecting container workloads. Application definitions describe what should run. Appropriate resource values, release safety, data protection and checks that represent application health still need to be designed by the team.
The control plane, worker nodes and application represent different areas of responsibility. Confirm which layers are managed by whom, alongside supported versions and integrations in the current service. Simplifying cluster administration does not eliminate application defects or the need to recover data.
Organise application configuration through reviewable definitions. Keep image versions, environment settings and deployment changes traceable.
Set CPU and memory requests using actual demand. Distinguish an individual container’s limits from the available capacity of the cluster.
Plan internal communication, external access and persistent data together. A pod’s lifecycle is not the same as the lifecycle of application data.
02 / Architecture
Illustrative Kubernetes layers: definitions reach cluster management and workloads run on nodes. Persistent data and recovery are planned around their own lifecycle.
Selection guide03 / Selection guide
| Consider | How to decide | Why it matters |
|---|---|---|
| Resource requests and limits | Measure CPU and memory requirements before setting requests and limits. | Missing or unsuitable values can affect scheduling and runtime behaviour. |
| Persistent data | Define the data lifecycle and a supported storage connection. | You need to know what happens to application data when a pod is recreated. |
| Networking and external access | Plan services, name resolution and incoming traffic together. | Ingress and load-balancing capabilities depend on the chosen integration. |
| Ownership and version policy | Document cluster, node and application responsibilities, maintenance and upgrades. | Supported platform versions and application dependencies need coordinated management. |
04 / Use cases
Define dependencies, resource requirements and coordinated releases. Evaluate the value of a consistent operating model as the service estate grows.
Plan validation of new images and recovery from a faulty release. Test compatibility between application updates and database changes.
Define repeatability, completion conditions and shared data access. Manage the effect of a failed job at the application level.
05 / From planning to operation
Define the container image, required settings and health checks. Keep secrets out of images and public repositories.
Define resource requests, node requirements and persistent storage connections. Verify support for the integrations the workload needs.
Exercise deployment, restarts and rollback from a failed release. Assess the outcome through application logs and resource measurements.
Define alerts, version maintenance and restore procedures. Test recovery of application data as well as cluster configuration.
No. A virtual server may be a clearer starting point for a single or simple service. Service count, release frequency and the team’s operating experience determine the need.
The control plane coordinates cluster management state; worker nodes run workloads. Confirm management and maintenance responsibilities for each layer within the chosen service.
A container’s temporary file system is not a persistent-data plan. Design and test supported persistent storage, application consistency and backup procedures.
Scaling requires appropriate components, metrics, resource capacity and application design. Verify the mechanisms supported by the service; the Kubernetes name alone is not a guarantee of automatic capacity.
Connect product decisions with installation, configuration and operating knowledge.
These references explain the technical concepts discussed on this page. Available configurations and service scope are defined by FibaCloud product and order information.
FIBACLOUD / Kubernetes
Tell us about your application, expected usage and operating requirements. Let’s bring the resource choices together.
