Kubernetes - Concepts
Autoheal allows you to keep the nodes in your pool in a healthy state. When enabled, periodic checks are performed to ensure your all your nodes are running properly.
Autoscale allows your cluster to automatically scale up or down.
Auto upgrade allows you to schedule a maintenance window for your cluster to be upgraded to a more recent version of Kubernetes. The upgrade process will occur within a two-hour timeframe starting from the time defined by you.
A cluster is a set of machines, called nodes, running containerized applications managed by Kubernetes. A cluster has several worker nodes and at least one control plane. Each cluster is built for High Availability with a redundancy on the Control Plane. Refer to the Control Plane concept for more information regarding the cluster’s limitations. Scaleway allows you to create two types of clusters: Kapsule, for clusters comprising Scaleway Instances, and Kosmos, for multi-cloud clusters.
Container Network Interface (CNI)
CNI (Container Network Interface) is a Cloud Native Computing Foundation project. It consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of plugins.
The container runtime is the software that is responsible for running containers.
The control plane manages the worker nodes and the Pods in the cluster. In production environments, the control plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability. The Control Plane and associated Load Balancers are managed by Scaleway. Consider the following when creating a Control Plane:
- A cluster belongs to one region
- As the cluster’s control plane and Load Balancer are managed by Scaleway, it is not possible to access them directly or to configure them individually.
- A cluster requires a minimum of one pool of worker machines in order to deploy Kubernetes resources. (Pods must run on a worker node).
The Easy Deploy feature allows you to pull images directly from Scaleway Container Registry, instantly deploying containerized applications in your Kubernetes Kapsule cluster. With only the basic options to set, you can use Kubernetes Kapsule without needing to manage your
.yaml manifests. Check out our documentation on creating containerized applications with the Easy Deploy feature for more information.
Image pull secret
Image pull secrets are tokens that authorize Kubernetes to pull images from private container registries.
Ingress is an API object that manages external access to the services in a cluster, typically HTTPS. Ingress can provide load balancing, SSL termination and name-based virtual hosting.
Kubernetes supports a high level abstraction called Ingress, which allows simple host or URL based HTTP routing. An ingress is a core concept (in beta) of Kubernetes, but is always implemented by a third party proxy. These implementations are known as ingress controllers. An ingress controller is responsible for reading the Ingress Resource information and processing that data accordingly. Different ingress controllers have extended the specification in different ways to support additional use cases. For more information, see our dedicated how-to on deploying ingress controllers.
kubeconfigis a file provided by Scaleway when creating a Kubernetes cluster. It allows you to manage your cluster from your local computer by using kubectl.
Kubectl is the command line interface for running commands against Kubernetes clusters. You can use kubectl to connect to and manage your clusters from the command line.
Kubernetes (K8s) is an open-source platform for managing containerized workloads and services. Google initially developed the project and it was made publicly available in 2014.
Kubernetes Kapsule provides a managed environment for you to create, configure and run a cluster of pre-configured machines for containerized applications. It allows you to create Kubernetes clusters without the complexity of managing the infrastructure. Kubernetes Kapsule clusters are composed uniquely of Scaleway Instances. Find out how to create a Kubernetes Kapsule here. To create clusters including Instances from external cloud providers, see Kubernetes Kosmos
Kubernetes Kosmos is the first-of-its-kind managed multi-cloud Kubernetes Engine. It allows the connection of Instances and servers from any Cloud provider to a single managed Control-Plane hosted by Scaleway. Using Kubernetes in a multi-cloud cluster provides a high level of application redundancy by authorizing pods replication across different providers, regions, and Availability Zones. See our documentation to learn how to create a Kubernetes Kosmos cluster.
Load balancing efficiently distributes incoming network traffic across a group of backend servers. Scaleway services manage the traffic between the API masters. The Load Balancer service is entirely managed by Scaleway.
Scaleway Kapsule and Kosmos are managed Kubernetes services. Scaleway’s managed Kubernetes service abstracts away the complexities of managing and operating a Kubernetes cluster, enabling developers to focus on application development and deployment while ensuring a reliable and scalable environment for running containerized workloads. These services allow users to focus on deploying and running applications on Kubernetes without having to worry about the underlying infrastructure and operational complexities.
For more information, refer to the managed Kubernetes service definition.
Minikube runs a single-node Kubernetes cluster inside a VM on your computer or cloud server for developing and testing applications. Minikube supports Kubernetes features such as:
- ConfigMaps and Secrets
- Container Runtime: Docker, rkt, CRI-O and containerd
- Enabling CNI (Container Network Interface)
Namespaces are used in Kubernetes to divide the same cluster resources between multiple virtual users. Namespaces are intended for use in environments with many users spread across multiple teams or projects.
Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the control plane and contains the services necessary to run Pods.
A Pod is the smallest and simplest unit in the Kubernetes object model. Containers are not directly assigned to hosts in Kubernetes. Instead, one or multiple containers that are working closely together are bundled in a Pod together, sharing a unique network address, storage resources and information on how to govern the containers.
The Pool resource is a group of Scaleway Instances, organized by type (e.g., GP1-S, GP1-M). It represents the computing power of the cluster and contains the Kubernetes nodes, on which the containers run. Consider the following when creating a Pool:
- Containers require a minimum of one Instance in the Pool.
- A pool belongs to only one cluster, in the same region.
The task of a ReplicaSet is to create and delete Pods as needed to reach the desired status. A ReplicaSet contains:
- Information about the number of pods it can acquire
- Information about the number of pods it maintains
- A Pod template, specifying the data of new Pods to meet the number of replicas criteria.
Each Pod within a ReplicaSet can be identified via the
metadata.ownerReferencefield, allowing the ReplicaSet to monitor each Pod’s state.
A service is an abstraction which defines a logical group of Pods that perform the same function, and a policy on how to access them. The service provides a stable endpoint (IP address) and acts as a Load Balancer by redirecting requests to the different pods in the service. The service abstraction allows the scaling out or replacement of dead pods without making changes to the configuration of an application.
By default, services are only available using internally routable IP addresses but can be exposed publicly.
This can be done by using the
NodePort configuration, which works by opening a static port on each node’s external networking interface. Alternatively, it is also possible to use the
load-balancer service, which creates an external Load Balancer at a cloud provider using Kubernetes
The system volume is a read-only volume that stores essential files for the Kubernetes system, such as runtime binaries, configuration files, and certificates. It is managed by the node and kept separate from application data.
Depending on the type of node selected, we provide one or two types of volume.
- Local storage: your system is stored locally on the hypervisor of your node.
- Block Storage: a remote storage, your system is stored on a centralized and resilient cluster.
As a general guideline, your system volume disk should have a capacity of at least 20 GB to ensure that there is enough space to store the necessary system files and configurations.