This is the second part of my Kubernetes Concepts Crash Course. See part one: https://www.taos.com/resources/blog/kubernetes-crash-course-part-1/
Arguments and Entry points
Arguments are added to an entry point (A initial command that is run when a container is created) when a container is created. To add arguments to the entry point in Kubernetes, the args filed can be set to an array of arguments under the container in the pod-definition file. To overwrite the entry point, set the command field
Environment Variables
To set environment variables in Kubernetes definition files, set env field to YAML array of name: value
ConfigMaps
A set of key-value pairs to be used in pod definition files.
Secrets
Like a configmap, but stored in a hash. When creating a secret definition file, you must specify the secrets in base 64 encoded format. To get this on a Linux host using the command echo -n | base64
Docker Security
Process Isolation
Within a container, only the processes on the container itself (AKA within its own namespace) are visible. On the docker host (The machine running docker that all the containers sit on top of), all processes in child containers/namespaces are visible.
Users
By default, all commands run on a container are run with the root user. If desired, the user can be specified
Root User in docker containers
By default, the root user does not have some capabilities, such as rebooting the host. These capabilities can be added with the –cap-add flag in the docker run and dropped with -the-cap-drop flag. To add all privileges use –privileged flag
Security Contexts
Let’s specify docker security concepts in the pod definition. Can set at either the pod level or the container level. Security Contexts at the container level will override security at the pod level.
Capabilities
Capabilities in the way docker containers use it can be added/removed at the container level only. With capabilities flag.
Resource Requirements
By default, Kubernetes assumes that a container in a pod requires .5 CPU and 256 MiB of memory. This is called its resource requests. A resource request is the minimum amount of a resource that is reserved for a container in a pod To change it, specify it under resources: requests in the container definition.
By default, Kubernetes sets a limit of vCPU per container and 512 MiB of memory per container. This is the maximum amount of resources that a container in a pod is allowed to use. This can be changed in the pod definition file with the key of the limits under resources. If a container tries to use more CPU than its limit, it will be throttled. However, if a container tries to use more memory, it can go over. If it goes over consistently, it will be terminated.
User accounts and service accounts
User Accounts are used by humans and service accounts are used by processes. When a service account is created, a token is created automatically. It is what must be used by the external service to communicate with the API. The token is stored in a secret object. If the service is an application deployed in the Kubernetes cluster, it can be mounted as a volume onto the service. That way the token is already placed inside the pod and can be easily read by the application.
Whenever a pod is created, the default service account and its token are automatically mounted onto the pod by default.
Taints and Tolerations
A taint prevents pods that do not have matching toleration from deploying to that node. Ex. A node has the “blue” taint. Only pods that have the “blue” toleration can deploy to it. Taints and tolerations do not tell a pod where to go. It simply says that only pods with certain toleration can be deployed there. A pod could be deployed anywhere it is tolerated. Node affinity is used to specify where a pod should be deployed
Taint Effects
A taint effect determines what happens to a pod that does not tolerate the taint. There are 3 types:
-
- NoSchedule: The pod will not be scheduled on the node
- PreferNoSchedule: System will try to not schedule a pod on the node
- NoExecute: New pods that do not tolerate the taint will not be scheduled AND existing pods that do not tolerate the taint will be evicted.
Node Selectors
Node Selectors let you specify what nodes to deploy a pod to based on node labels. It is a very simple and relatively limited way to specify nodes in Kubernetes. You cannot do complex rules like or not. For more complex rules, node affinity would be required
Node Affinity
Node Affinity allows you to specify what node(s) you want your containers to deploy on. It allows more complex rules like exists, in, on, etc. There are currently 2 types of affinity available:
-
- requiredDuringSchedulingIgnoredDuringExecution: If a pod cannot be placed on a node with the correct label, it will not be placed
- preferredDuringSchedulingIgnoredDuringExecution: If a pod cannot be placed on a node with the correct label, it will ignore affinity rules