Day6#30daysofK8s

Secrets can be stored in the secrets definition file in the form of either an unencrypted base64 encoded string(data) or in a normal string(stringData).

stringData key gets precedence over the data key. Both keys can be defined in the definition file.

base64 encoded string is unencrypted because anyone with the encoded string can also decode it.

There are different types of secrets, the default one is opaque .

The secret is only shared with node if a pod on the node requires the secret. When the pod is deleted, node’s copy of the secret will also be deleted.

To have a more protection over the secret data, RBAC could be implemented or enable encryption at REST(whatever that means).

Multicontainer pods — it is what the name suggests. A single pod running multiple containers. The reason this is done is to compliment an easy scalling. If 2 services need to be used together, it makes sense to deploy then and destroy them together and this is done by deploying them in a single pod, hence multicontainer pod.

multicontainer-pod-def.yaml
apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod-1
spec:
  containers:
  - name: nginx-container
    image: nginx
  - name: mysql-container
    image: sql

Executing something inside the pod — k exec app -it cat /log/app.log

alias mcp= "multi-container pod"

Every container in a MCP is expected to run until the pod’s lifecycle ends. If any of the container terminates unexpectedly, the pod is restarted.

But there might be containers that are required only as a part of setup. In such cases we can use initContainer . These containers are expected to finish their process before the actual containers can start their process. If the initContainer fails to finish it’s process, the pod will be restarted.

It is also possible to use multiple initContainer but their processes will be executed sequentially. Until initContainer -1 is executed initContainer -2 will not be executed and so on.

Examples of stuff that can be done with initContainer — 1) clone a repository, 2) copy files, 3) waiting for some time before starting some container, 4) wait for a service to be created

initContainer is different container in a way that it does not support liveliness and readiness checks.

initContainer-pod-def.yaml
apiVersion: v1
kind: Pod
metadata:
  name: initcontainer-pod
spec:
  containers:
  - image: nginx
    name: nginx-container
  - image: mysql
    name: mysql-container
  initContainers:
  - name: initC1
    image: sleeper-img
    command: ["sleep", "60"]
  - name: initC2
    image: clone-img
    command: ["git", "clone", "https://github.com/some-repo.git"]

alias k=kubectl

controlplane $ k get pods
NAME    READY   STATUS     RESTARTS   AGE
blue    0/1     Init:0/1   0          9s    <- initContainer running
green   2/2     Running    0          9s
red     1/1     Running    0          10s

• initContainer’s state will be terminated once it completes it’s process.

Init Containers:
  init-myservice:
    Image:         busybox
    Command:
      sh
      -c
      sleep 5
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Sun, 07 Feb 2021 08:57:29 +0000
      Finished:     Sun, 07 Feb 2021 08:57:34 +0000
    Ready:          True