A pod is the smallest deployable unit in Kubernetes. A Pod represents a single instance of a running process in your cluster.
Pods deploy a container image on a Kubernetes cluster as a running instance of an application.
A pod can contain more than one container.
An example use case would be a pod that contains a web server and a sidecar container that collects logs for the web server container.
A pod can be deployed by using kubectl or by creating a YAML manifest:
kubectl run my-pod --image=my-image
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
- containers:
- name: my-container
image: my-image
You can view pods running in a cluster by using the following command:
kubectl get pods
You can view detailed information about a pod by using the following command:
kubectl describe pod my-pod
ReplicaSets are a lower-level concept that manages Pods and ensures a specified number of pod replicas are running at any given time.
Deployments are a higher-level concept that manage ReplicaSets and provide declarative updates to Pods along with a lot of other useful features.
Namespaces are a way to divide cluster resources between multiple users.
Namespaces can be used to organize resources and provide a way to scope resources.
Namespaces can be used to create resource quotas and limit the amount of resources a user can consume.
Namespaces can be used to create network policies and limit the network traffic between pods.
Namespaces can be used to create role-based access control (RBAC) policies and limit the permissions of users.
Imperative:
Imperative commands are used to perform a specific task.
An example of an imperative command would be to create a pod using kubectl run.
Imperative commands are useful for quick tasks and testing.
Declarative:
Declarative commands are used to define the desired state of a resource.
An example of a declarative command would be to create a pod using a YAML manifest.
Declarative commands are useful for managing resources in a production environment.
Scheduling is the process of assigning pods to nodes in a Kubernetes cluster.
The Kubernetes scheduler is responsible for scheduling pods to nodes based on resource requirements and constraints.
The scheduler uses a set of policies to determine where to place pods in the cluster.
The scheduler can be configured to use different scheduling algorithms and policies.
The scheduler can be extended with custom scheduling plugins.
To schedule a pod, the scheduler evaluates the pod’s resource requirements, affinity and anti-affinity rules, taints and tolerations, and other constraints. It then selects a node that meets the requirements and assigns the pod to that node by updating the spec.nodeName field in the pod’s manifest.
Labels are key-value pairs that are attached to objects in Kubernetes.
Labels can be used to organize and select objects in Kubernetes.
Labels can be used to filter and group objects in Kubernetes.
Labels can be used to create selectors that match objects based on their labels.
Selectors are used to select objects in Kubernetes based on their labels.
Selectors can be used to filter objects based on their labels.
Selectors can be used to group objects based on their labels.
Selectors can be used to create sets of objects that match a specific label query.
Taints are used to repel pods from nodes in a Kubernetes cluster.
We apply a taint to a node (as a key-value pair). Any pods that do not have a toleration for that taint will not be scheduled on that node.
Node selectors are used to constrain which nodes a pod is eligible to be scheduled based on labels on the node.
Node selectors are used to filter nodes based on their labels.
To use a node selector, you add a nodeSelector field to the pod’s spec that specifies a set of key-value pairs that must match the labels on the node.
Example:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
nodeSelector:
disktype: ssd
Node affinity is a way to constrain which nodes a pod is eligible to be scheduled based on labels on the node.
Node affinity is similar to node selectors but provides more control over how pods are scheduled.
Node affinity can be used to specify required and preferred rules for node selection.
Node affinity can be used to specify rules that match or do not match nodes based on their labels.
Node affinity can be used to specify rules that match or do not match nodes based on their topology.
Example:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values:
- ssd
Requests and limits are used to specify the amount of resources a pod requires and the maximum amount of resources a pod can consume.
Requests are used to specify the amount of resources a pod requires to run.
Limits are used to specify the maximum amount of resources a pod can consume.
Requests and limits can be specified for CPU and memory resources.
Requests and limits can be specified in the pod’s spec.
Example:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
DaemonSets are used to run a copy of a pod on all nodes in a Kubernetes cluster.
DaemonSets are used to run system daemons and other background tasks on all nodes.
DaemonSets are defined by a YAML manifest that specifies the pod template to use.
DaemonSets can be deployed by creating a YAML manifest:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: my-daemonset
spec:
selector:
matchLabels:
app: my-daemonset
template:
metadata:
labels:
app: my-daemonset
spec:
containers:
- name: my-container
image: my-image
Static Pods are pods that are managed by the kubelet on a node.
Static Pods are defined by a file on the node’s filesystem.
Static Pods are not managed by the Kubernetes API server.
Static Pods are useful for running system daemons and other background tasks on a node.
Static Pods are defined by a file in the /etc/kubernetes/manifests directory on the node.
Static Pods are created and managed by the kubelet on the node.
Kubernetes supports multiple schedulers that can be used to schedule pods in a cluster.
You can even create your own schedule and use it to schedule pods in a cluster.
Authentication is the process of verifying the identity of a user or system.
Kubernetes supports multiple authentication methods, including:
X.509 client certificates
Static tokens
Service accounts
OpenID Connect tokens
Webhook tokens
Authorization is the process of determining what actions a user or system is allowed to perform.
Kubernetes supports multiple authorization methods, including:
Role-based access control (RBAC)
Attribute-based access control (ABAC)
API groups are used to organize resources in Kubernetes.
API groups are used to group related resources together.
API groups that you will commonly use:
core: Contains core resources like pods, services, and namespaces.
apps: Contains higher-level resources like deployments, replica sets, and stateful sets.
batch: Contains resources like jobs and cron jobs.
extensions: Contains deprecated resources like replica sets and daemon sets.
networking.k8s.io: Contains resources like network policies and ingresses.
storage.k8s.io: Contains resources like storage classes and persistent volume claims.
rbac.authorization.k8s.io: Contains resources like roles and role bindings.
metrics.k8s.io: Contains resources like pod metrics.
autoscaling: Contains resources like horizontal pod autoscalers.
admissionregistration.k8s.io: Contains resources like mutating webhooks and validating webhooks.
Example:
curl -k https://<master-ip>:6443/apis/apps/v1
Role-based access control (RBAC) is a method of restricting access to resources based on the roles of users or systems.
Service Accounts are created and managed by the Kubernetes API and can be used for machine authentication
To create a service account: kubectl create serviceaccount <account name>
Service accounts are namespaced
When a service account is created, it has a token created automatically. The token is stored as a secret object.
You can also use the base64 encoded token to communicate with the Kube API Server:
curl https://172.16.0.1:6443/api -insecure --header "Authorization: Bearer <token value>"
You can grant service accounts permission to the cluster itself by binding it to a role with a rolebinding. If a pod needs access to the cluster where it is hosted, you you configure the automountServiceAccountToken boolean parameter on the pod and assign it a service account that has the appropriate permissions to the cluster. The token will be mounted to the pods file system, where the value can then be accessed by the pod. The secret is mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.
A service account named ‘default’ is automatically created in every namespace
As of kubernetes 1.22, tokens are automatically mounted to pods by an admission controller as a projected volume.
https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md
As of Kubernetes 1.24, when you create a service account, a secret is no longer created automatically for the token. Now you must run kubectl create token <service account name> to create the token.
https://github.com/kubernetes/enhancements/issues/2799