Pod
1.1 Concept
1.1.1 Multi-container POD
At times you may need two services to work together such as a web server and a logging service, but you'd still like them to be developed and deployed separately and you only need the two functionality to work together. Then you need multi container pod.
1.1.1.1 Multi-container PODs Design Patterns
There are 3 common patterns, when it comes to designing multi-container PODs. The first and what we just saw with the logging service example is known as a side car pattern. The others are the adapter and the ambassador pattern.
1.1.1.2 InitContainer
When a POD is first created the initContainer is run, and the process in the initContainer must run to a completion before the real container hosting the application starts.
You can configure multiple such initContainers as well, like how we did for multi-pod containers. In that case each init container is run one at a time in sequential order.
If any of the initContainers fail to complete, Kubernetes restarts the Pod repeatedly until the Init Container succeeds.
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
Reference:
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
1.2 Configuration
1.2.1 Container
1.2.1.1 Arguments
1.2.1.2 Env Variables
1.2.2 Security Context
In the securityContext, you can define the user to run the container and capabilities.
You may choose to configure the security settings at a container level or at a pod level.
- If you configure it at a pod level the settings will carry over to all the containers within the pod.
- If you can figure it at both the pod and the container the settings on the container will override the settings on the pod
- Capabilities can only be configured at container level.
1.3 Edit
Remember, you CANNOT edit specifications of an existing POD other than the below.
- spec.containers[*].image
- spec.initContainers[*].image
- spec.activeDeadlineSeconds
- spec.tolerations
But if you really want to, you have 2 options:
1.3.1 Edit directly
kubectl edit pod <pod name>
1.3.2 Edit by recreating with YAML
kubectl get pod webapp -o yaml > my-new-pod.yaml
vi my-new-pod.yaml
kubectl delete pod webapp
kubectl create -f my-new-pod.yaml
1.4 Network
Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. We give every pod its own cluster-private-IP address. This means that containers within a Pod can all reach each other’s ports on localhost, and all pods in a cluster can see each other without NAT. And you can also reach any port from any other pod or node in your cluster using the pot cluster IP.
