The master node hosts the control plane components, which are responsible for managing the cluster and orchestrating its operations.
- Provides the Kubernetes API, the primary interface for interacting with the cluster.
- Processes RESTful API requests, performs authentication and authorization, and updates the cluster state stored in etcd.
- Assigns pods to nodes based on resource requirements, node constraints, and other factors specified in the pod's configuration.
- Ensures pods are scheduled onto suitable nodes within the cluster.
- Includes various controllers responsible for managing different aspects of the cluster's state and performing reconciliation loops.
- Examples of controllers: Replication Controller, ReplicaSet Controller, Endpoint Controller.
- Node controller: Responsible for noticing and responding when nodes go down.
- Job controller: Watches for Job objects that represent one-off tasks, then creates Pods to run those tasks to completion.
- EndpointSlice controller: Populates EndpointSlice objects (to provide a link between Services and Pods).
- ServiceAccount controller: Create default ServiceAccounts for new namespaces.
- A distributed key-value store that serves as the cluster's backing store for all persistent data.
- Stores the cluster's configuration data, state information, and metadata about objects such as pods, services, and nodes.
Worker nodes (also known as worker or minion nodes) are responsible for running the actual workloads, including containers/pods.
- The container runtime, such as Docker or containerd, runs containerized applications within pods on the worker node.
- Manages the lifecycle of containers, including image downloading, container creation, starting, stopping, and deleting.
- An agent that runs on each worker node, responsible for managing containers, pods, and their associated resources.
- Communicates with the Kubernetes API server to receive instructions about pod deployment, management, and health monitoring.
- A network proxy that runs on each worker node, responsible for implementing Kubernetes networking services.
- Maintains network rules on nodes and performs network address translation (NAT) for pods to ensure proper routing within the cluster.
A Kubernetes pod is a collection of one or more Linux® containers and is the smallest unit of a Kubernetes application. Pods share volume and network resources and specify how to run the containers.
- Ensures a specified number of pod replicas are running at any given time.
- Manages ReplicaSets and Pods.
- Provides declarative updates to pods and ReplicaSets, ensuring a specified number of pods are running at any given time.
- Offers features like scaling, rolling updates, and rollback functionality.
namespaces provide a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects (e.g. Deployments, Services, etc.) and not for cluster-wide objects
A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.
Some typical uses of a DaemonSet are:
- running a cluster storage daemon on every node
- running a logs collection daemon on every node
- running a node monitoring daemon on every node
ReplicaSet: Ensures a specified number of Pod replicas are running at any given time.
DaemonSet: Ensures that a copy of a specific Pod runs on all (or some) nodes in the cluster.
A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created. Suspending a Job will delete its active Pods until the Job is resumed again.
A simple case is to create one Job object in order to reliably run one Pod to completion. The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot).
You can also use a Job to run multiple Pods in parallel.
A CronJob creates Jobs on a repeating schedule.
CronJob is meant for performing regular scheduled actions such as backups, report generation, and so on. One CronJob object is like one line of a crontab (cron table) file on a Unix system. It runs a Job periodically on a given schedule, written in Cron format.
A ConfigMap is an API object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume.
A ConfigMap allows you to decouple environment-specific configuration from your container images, so that your applications are easily portable.
- Use a ConfigMap for setting configuration data separately from application code.
A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in a container image. Using a Secret means that you don't need to include confidential data in your application code.
Because Secrets can be created independently of the Pods that use them, there is less risk of the Secret (and its data) being exposed during the workflow of creating, viewing, and editing Pods. Kubernetes, and applications that run in your cluster, can also take additional precautions with Secrets, such as avoiding writing sensitive data to nonvolatile storage.
You can use Secrets for purposes such as the following:
Set environment variables for a container. Provide credentials such as SSH keys or passwords to Pods. Allow the kubelet to pull container images from private registries.
- ConfigMaps: Typically used to store configuration data, such as environment variables.
- Secrets: Store sensitive data, such as passwords and API keys.
A StatefulSet is a special type of workload object used to manage stateful applications. Unlike Deployments, which are designed for stateless applications, StatefulSets are used when the application requires stable, unique network identities, persistent storage, and ordered deployment, scaling, and updates.
Using StatefulSets StatefulSets are valuable for applications that require one or more of the following.
- Stable, unique network identifiers.
- Stable, persistent storage.
- Ordered, graceful deployment and scaling.
- Ordered, automated rolling updates.
Pod Management Policies StatefulSet allows you to relax its ordering guarantees while preserving its uniqueness and identity guarantees via its .spec.podManagementPolicy field.
OrderedReady Pod Management OrderedReady pod management is the default for StatefulSets. It implements the behavior described above.
In a Kubernetes cluster, files in a container are considered short-lived. If the pod is gone, the data it had is also gone. Kubernetes volumes solve this problem. A volume is a directory accessible to the containers in a pod, and the data in the volume will persist regardless of what happens to the containers.
- Persistent Volume (PV): A piece of storage in the Kubernetes cluster.
- Persistent Volume Claim (PVC): A request for storage by a user.
A Service is an abstraction layer that defines a logical set of Pods and a policy by which to access them. Services enable decoupling of the network connectivity from the lifecycle of Pods. There are different types of Services in Kubernetes, each serving a specific purpose.
- Selectors: Services use label selectors to identify the set of Pods they should forward traffic to.
- Endpoints: A Service creates a list of endpoints that it maps to the selected Pods.
Kubernetes Services provide a stable endpoint (IP address and DNS name) to access one or multiple Pods.
version number follows the Semantic Versioning (SemVer) convention, which consists of three parts:
major.minor.patch.
Major version
Indicates a major release that includes significant changes or new features that might be incompatible with previous versions. A change in the major version suggests breaking changes that could potentially require modifications to your existing deployments or configurations.
Minor version (5):
Denotes a minor release that adds new functionality or features in a backward-compatible manner. It might also include improvements and enhancements, but without breaking the existing functionality.
Patch version (8):
Represents a patch release that typically includes bug fixes, security patches, or other minor updates that are backward-compatible. These changes are intended to improve the stability and performance of the existing features without adding new functionality.
So, version 2.5.8 of Kubernetes can be broken down as:
2: Major version, indicating significant changes or potential incompatibility with previous major versions.
5: Minor version, indicating backward-compatible new features and improvements.
8: Patch version, indicating backward-compatible bug fixes and minor updates.
Keep Up with Updates:
- Regularly update your Kubernetes components to benefit from the latest features, performance improvements, and security patches. Delaying updates can expose your cluster to known vulnerabilities and compatibility issues.
| Port | Object | Description |
|---|---|---|
| 6443 | API Server | Kubernetes API server listens on this port for API requests from kubectl, other components, and external clients. |
| 2379 | etcd | etcd server client requests (cluster store). |
| 2380 | etcd | etcd server peer communication (used for clustering). |
| 10250 | Kubelet | Kubelet API (for communicating with the API server). |
| 10255 | Kubelet (Read-Only) | Read-only Kubelet API (deprecated, use 10250 instead). |
| 10257 | Kube Controller Manager | Kubernetes controller manager listens on this port for secure communication. |
| 10259 | Kube Scheduler | Kubernetes scheduler listens on this port for secure communication. |
| 10256 | Kube Proxy | Kube proxy metrics (for monitoring and debugging). |
| 10254 | Ingress Controller | Default port for health checks for NGINX ingress controller. |
| 30000-32767 | NodePort Services | Ports used by NodePort services to expose applications outside the cluster. |
Note: Ports may vary depending on the specific configuration and the chosen networking solution.
- Request: The amount of resources that will get reserved for you.
- Limit: The amount of resources that will get limited to and can't take more.