You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pages/kubernetes/reference-content/introduction-to-kubernetes.mdx
+16-12Lines changed: 16 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -44,7 +44,7 @@ Kubernetes is able to manage a cluster of virtual or physical machines using a s
44
44
45
45
Each machine in a Kubernetes cluster has a given role within the Kubernetes ecosystem. One of these servers acts as the **control plane**, the "brain" of the cluster exposing the different APIs, performing health checks on other servers, scheduling the workloads and orchestrating communication between different components. The control plane acts as the primary point of contact with the cluster.
46
46
47
-
The other machines in the cluster are called **nodes**. These machines are designed to run workloads in containers, meaning each of them requires a container runtime installed on it (for example, [Docker](/tutorials/install-docker-ubuntu-bionic/) or [CRI-O](https://cri-o.io/)).
47
+
The other machines in the cluster are called **nodes**. These machines are designed to run workloads in containers, meaning each of them requires a container runtime installed on it (for example, `containerd`).
48
48
49
49
The different underlying components running in the cluster ensure that the desired state of an application matches the actual state of the cluster. To ensure the desired state of an application, the control plane responds to any changes by performing necessary actions. These actions include creating or destroying containers on the nodes and adjusting network rules to route and forward traffic as directed by the control plane.
50
50
@@ -94,16 +94,16 @@ Node components are maintaining pods and providing the Kubernetes runtime enviro
94
94
95
95
The `kubelet` is an agent running on each node and ensuring that containers are running in a pod. It makes sure that containers described in `PodSpecs` are running and healthy. The agent does not manage any containers that were not created by Kubernetes.
96
96
97
-
#### `kube-proxy`
97
+
#### `kube-proxy` (optional)
98
98
99
99
The `kube-proxy` is a network proxy running on each node in the cluster. It maintains the network rules on nodes to allow communication to the pods inside the cluster from internal or external connections.
100
100
101
101
`kube-proxy` uses either the packet filtering layer of the operating system, if there is one, or forwards the traffic itself if there is none.
102
102
103
-
### Container runtime
103
+
####Container runtime
104
104
105
105
Kubernetes is able to manage containers, but is not capable of running them. Therefore, a container runtime is required that is responsible for running containers.
106
-
Kubernetes supports several container runtimes like `Docker` or `containerd` as well as any implementation of the [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
106
+
Kubernetes Kapsule supports the `containerd` container runtimes as well as any implementation of the [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
107
107
108
108
## Kubernetes objects
109
109
@@ -119,33 +119,37 @@ A **service** is an abstraction which defines a logical group of pods that perfo
119
119
120
120
By default, services are only available using internally routable IP addresses, but can be exposed publicly.
121
121
122
-
It can be done either by using the `NodePort` configuration, which works by opening a static port on each node's external networking interface. Otherwise, it is possible to use the `LoadBalancer` service, which creates an external Load Balancer at a cloud provider using Kubernetes load-balancer integration.
122
+
It can be done either by using the `NodePort` configuration, which works by opening a static port on each node's external networking interface. Otherwise, it is possible to use the `LoadBalancer` service, which creates an Scaleway Load Balancer using Kubernetes load-balancer integration, provided by the CCM.
123
+
124
+
<Messagetype="note">
125
+
To use `NodePort` with Kubernetes Kapsule or Kosmos, security groups for Scaleway Instances must be configured to allow external connections to the exposed ports of the nodes.
126
+
</Message>
123
127
124
128
### ReplicaSet
125
129
126
-
A **ReplicaSet** contains information about how many pods it can acquire, how many pods it shall maintain, and a pod template specifying the data of new pods to meet the number of replicas criteria. The task of a ReplicaSet is to create and delete pods as needed to reach the desired status.
130
+
A `ReplicaSet` contains information about how many pods it can acquire, how many pods it shall maintain, and a pod template specifying the data of new pods to meet the number of replicas criteria. The task of a ReplicaSet is to create and delete pods as needed to reach the desired status.
127
131
128
132
Each pod within a ReplicaSet can be identified via the `metadata.ownerReference` field, allowing the ReplicaSet to know the state of each of them. It can then schedule tasks according to the state of the pods.
129
133
130
134
However, `Deployments` are a higher-level concept managing ReplicaSets and providing declarative updates to pods with several useful features. It is therefore recommended to use Deployments unless you require some specific customized orchestration.
131
135
132
136
### Deployments
133
137
134
-
A Deployment is representing a set of identical pods with no individual identities, managed by a _deployment controller_.
138
+
A `Deployment` in Kubernetes provides declarative updates for applications. It manages `ReplicaSets`, which in turn manage the actual Pods.
135
139
136
-
The deployment controller runs multiple replicas of an application as specified in a _ReplicaSet_. In case any pods fail or become unresponsive, the deployment controller replaces them until the actual state equals the desired state.
140
+
The deployment controller continuously ensures that the desired number of Pod replicas are running. If Pods fail, become unresponsive, or are deleted, it automatically creates replacements to match the desired state. Deployments also support rolling updates and rollbacks, making them the standard way to manage stateless applications.
137
141
138
142
### StatefulSets
139
143
140
-
A StatefulSet is able to manage pods like the deployment controller but maintains a sticky identity of each pod. Pods are created from the same base, but are not interchangeable.
144
+
A `StatefulSet` manages Pods in a similar way to a Deployment, but with one crucial difference: each Pod has a **persistent identity** and is **not interchangeable**. Pods are created from the same specification, yet each one gets a unique, ordinal-based name that persists even if the Pod is rescheduled to a different node.
141
145
142
-
The operating pattern of StatefulSet is the same as for any other Controllers. The StatefulSet controller maintains the desired state, defined in a StatefulSet object, by making the necessary update to go from the actual state of a cluster to the desired state.
146
+
Like other controllers, the StatefulSet controller continuously reconciles the cluster’s actual state with the desired state defined in the StatefulSet object.
143
147
144
-
The unique, number-based name of each pod in the StatefulSet persists, even if a pod is being moved to another node.
148
+
Because Pods are treated as unique, each can be associated with its own dedicated storage volume. This makes StatefulSets the preferred choice for workloads that require **stable network identities, persistent storage, and ordered deployment or scaling** — such as databases and distributed systems.
145
149
146
150
### DaemonSets
147
151
148
-
Another type of pod controller is called DaemonSet. It ensures that all (or some) nodes run a copy of a pod. For most use cases, it does not matter where pods are running, but in some cases, it is required that a single pod runs on all nodes. This is useful for aggregating log files, collecting metrics, or running a network storage cluster.
152
+
Another type of pod controller is called `DaemonSet`. It ensures that all (or some) nodes run a copy of a pod. For most use cases, it does not matter where pods are running, but in some cases, it is required that a single pod runs on all nodes. This is useful for aggregating log files, collecting metrics, or running a network storage cluster.
0 commit comments