Kubernetes uses rollouts to updates the deployments, which includes replacing the replicas that matches the specs in the new deployment template. Other changes could also include environment variables, labels, and code changes.
To learn more, check out Rollouts and Rollbacks
We can simply create environment variables by using the env property, followed by a key-value pairs of variables. As example:
apiVersion: v1
kind: Pod
metadata:
name: myapp
labels:
name: myapp
spec:
containers:
- name: myapp
image: <Image>
ports:
- containerPort: <Port>
env:
- name: USERNAME
value: paul
- name: DEPARTMENT
value: finance
- name: ROLE
value: read-only
Other ways of setting environment variables are through:
The main difference is how the variables are defined in the Pod manifest;
# Set the environment variables directly in the Pod manifest
env:
- name: USERNAME
value: paul
# Pull the environment variables from a COnfigMap
env:
- name: USERNAME
valuefrom:
configMapKeyRef:
# Pull the environment variables from a Secret
envFrom:
- secretRef:
name: USERNAME
ConfigMaps are used to decouple configuration artifacts from container image content to keep containerized applications portable. The configuration data is stored as key-value pairs in a YAML file separate from the actual Deployment manifest.
On the other hand, Secrets are specifically used for storing sensitive information. Secrets reduce the risk of accidental exposure compared to if they were stored in an image or put in a Pod specification.
To learn more, check out ConfigMaps and Secrets
With multi-container Pods, we have a number of Pods that share the same lifecycle, which means these Pods are created together and destroyed together.