A pod is the atomic unit of scheduling. Containers inside a pod share network and storage resource.
The most common use of a Pod is to run a single container. Situations where different processes work on the same shared resource benefit from having multiple containers in a single Pod.
Some projects inject containers into running Pods to deliver a service. An example of this is the Istio service mesh, which uses this injected container as a proxy for all communication.
Kubernetes master cluster that includes:
etcd cluster is part of it too (but it can be separated).
Create multiple virtual clusters on the same physical clusters. You can limit resources such as CPU per namespace.
In Kubernetes you typically manage the configuration of pods and replicat set through a
--- apiVersion: apps/v1 kind: Deployment metadata: name: xxx namespace: xxx spec: replicas: 2 selector: matchLabels: app: xxx strategy: type: RollingUpdate (1) template: metadata: labels: xxx app: xxx spec: containers: - name: xxx image: 'cicd-docker.repository.irisnet.be/xxx@sha256:075e27c6d210a1605d34946b70282a10b585768b0aa299345c90f98f65ef73e0' (2) imagePullPolicy: IfNotPresent (3) restartPolicy: Always (4) dnsPolicy: ClusterFirst (5)
|1||RollingUpdate (updates one pod at a time) the default or Recreate|
|2||avoid the usage of the tag 'latest’|
|3||can be omit if you use sha id|
|4||can be omit; Always is the default|
|5||can be omit; ClusterFirst is the default|
Appropriate for situations where Pods have a similar definition but need a unique identity, ordered deployment and scaling, and storage that persists across Pod rescheduling.
Separate sensible information and flag them as such.
Don’t provide encryption (Base64 encoded).
Set of key/value pairs
Detect if a container becomes unresponsive (need to be restarted)
Detect if a ready to start accepting traffic.