Configuration
ConfigMaps
ConfigMaps allow you to store and manage non-sensitive configuration data in key-value pairs. They can be used to configure application settings, environment variables, command-line arguments, and more. ConfigMaps decouple configuration from application code, making it easier to update and manage configurations separately.
SecurityContext
The security context provides an additional layer of security by controlling how containers interact with the underlying system and other containers. It helps enforce security policies and ensures that applications are running in a secure environment.
It allows you to specify the privileges, access controls, and security-related configurations for running applications within a cluster.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
# Example
securityContext:
runAsUser: 1000
runAsGroup: 2000
containers:
- name: my-container
image: nginx:latest
# Example
securityContext:
capabilities:
add: ["SYS_ADMIN", "SYS_TIME"]
You can find a comprehensive list of capabilities and their descriptions in the Linux kernel documentation: Linux Capabilities
Resource Requirements
Resource Quotas and Limits help manage resource allocation in a Kubernetes cluster. Resource Quotas define the maximum amount of compute resources (CPU, memory, etc.) that can be consumed within a namespace. Resource Limits set the maximum resource consumption for individual pods or containers. These components ensure fair allocation of resources and prevent resource abuse.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:latest
# Example
resources:
requests:
cpu: "500m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"
Secrets
Secrets are used to securely store sensitive information, such as passwords, API keys, or TLS certificates, within Kubernetes. Secrets encrypt the data at rest and provide a convenient way to distribute and manage sensitive information to the applications running in the cluster.
Service Accounts
ServiceAccounts are used to provide an identity for pods running within a Kubernetes cluster. They allow pods to authenticate with the cluster’s API server and access other cluster resources securely. ServiceAccounts are associated with a set of permissions, defined through Role-Based Access Control (RBAC), to control access to various resources.
Taints and Tolerations
Taints are applied to Kubernetes nodes to indicate restrictions or requirements, while tolerations are set on pods to specify their willingness to tolerate certain taints.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:latest
tolerations:
- key: special-workload
operator: "Equal"
value: "true"
effect: NoSchedule
nodeSelector:
my-node-label: my-node-value
tolerations: This field specifies the tolerations for the pod. In our example, we have a single toleration defined. It has the key “special-workload” with a value of “true”. The operator is set to “Equal”, indicating an exact match. The effect is set to “NoSchedule”, which means that the pod will not be scheduled on nodes with the specified taint.
nodeSelector: This field specifies the node label(s) that the pod should be scheduled on. It is unrelated to taints and tolerations but included here for completeness. You can use node selectors to further refine the scheduling of pods based on specific node labels.
Node Selectos and Node Affinity
NodeSelector is a way to instruct Kubernetes to schedule pods on nodes that match specific labels. It allows you to define the requirements for the nodes where your pods should be deployed.
1
2
3
4
5
6
7
8
9
10
11
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:latest
# example of nodeSelector
nodeSelector:
app: frontend
NodeAffinity is an advanced feature that provides more flexibility in defining rules for pod scheduling based on node attributes such as labels, node names, or resource availability.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:latest
affinity:
# example of node affinity
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: app
operator: In
values:
- frontend
- backend
Note
Both nodeSelector and nodeAffinity provide ways to control pod scheduling based on node attributes. While nodeSelector offers a simpler approach with basic label matching, nodeAffinity provides more advanced capabilities for fine-grained control over pod placement by allowing complex rules based on various node attributes.