Nodes [page]deterministic
Kubernetes runs your [workload](#gloss:workload) by placing [containers](#gloss:container) 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](#gloss:control-plane) and contains the services necessary to run [Pods](#gloss:pod).
Typically you have several nodes in a cluster; in a learning or resource-limited environment, you might have only one node.
The [components](/docs/concepts/architecture/#node-components) on a node include the [kubelet](#gloss:kubelet), a [container runtime](#gloss:container-runtime), and the [kube-proxy](#gloss:kube-proxy).
## Management
There are two main ways to have Nodes added to the [API server](#gloss:kube-apiserver):
1. The kubelet on a node self-registers to the control plane 2. You (or another human user) manually add a Node object
After you create a Node [object](#gloss:object), or the kubelet on a node self-registers, the control plane checks whether the new Node object is valid. For example, if you try to create a Node from the following JSON manifest:
```json { "kind": "Node", "apiVersion": "v1", "metadata": { "name": "10.240.79.157", "labels": { "name": "my-first-k8s-node" } } } ```
Kubernetes creates a Node object internally (the representation). Kubernetes checks that a kubelet has registered to the API server that matches the `metadata.name` field of the Node. If the node is healthy (i.e. all necessary services are running), then it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity until it becomes healthy.
> Note: Kubernetes keeps the object for the invalid Node and continues checking to see whether it becomes healthy.
You, or a , must explicitly delete the Node object to stop that health checking.
The name of a Node object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
### Node name uniqueness
The [name](/docs/concepts/overview/working-with-objects/names#names) identifies a Node. Two Nodes cannot have the same name at the same time. Kubernetes also assumes that a resource with the same name is the same object. In the case of a Node, it is implicitly assumed that an instance using the same name will have the same state (e.g. network settings, root disk contents) and attributes like node labels. This may lead to inconsistencies if an instance was modified without changing its name. If the Node needs to be replaced or updated significantly, the existing Node object needs to be removed from API server first and re-added after the update.
### Self-registration of Nodes
When the kubelet flag `--register-node` is true (the default), the kubelet will attempt to register itself with the API server. This is the preferred pattern, used by most distros.
For self-registration, the kubelet is started with the following options:
- `--kubeconfig` - Path to credentials to authenticate itself to the API server.
- `--cloud-provider` - How to talk to a [cloud provider](#gloss:cloud-provider) to read metadata about itself.
- `--register-node` - Automatically register with the API server.
- `--register-with-taints` - Register the node with the given list of [taints](#gloss:taint) (comma separated `<key>=<value>:<effect>`).
No-op if `register-node` is false. - `--node-ip` - Optional comma-separated list of the IP addresses for the node. You can only specify a single address for each address family. For example, in a single-stack IPv4 cluster, you set this value to be the IPv4 address that the kubelet should use for the node. See [configure IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack/#configure-ipv4-ipv6-dual-stack) for details of running a dual-stack cluster.
If you don't provide this argument, the kubelet uses the node's default IPv4 address, if any; if the node has no IPv4 addresses then the kubelet uses the node's default …(trimmed)