A container is a stand-alone, executable piece of software which includes everything that is required to run it. Such as code, libraries and any external dependencies. It ensures that what is running is identical, even when running in a different environment. This is achieved by isolating the running code from its execution context.
This is achieved in Linux by carving a subset of the Linux Kernel using an API called cgroups. This provides a high amount of isolation from the operating system, but without the runtime performance hit of virtualised environments such as VMWare, KVM, etc.
The pod is the most basic of objects that can be found in Kubernetes.
A pod is a collection of containers, with shared storage and network, and a specification on how to run them. Containers within a pod share an IP address and port space, and can find each other via localhost.
Each pod is allocated its own IP address.
A pod should be seen as an ephemeral primitive.
A replicaset
runs n number of a pod, based on the provided template.
Replicasets are not use directly, however the resource needs to be understood as it is the based building block for building applications on Kubernetes.
Replicasets can (when instructed to) scale up or down the number of pods which are desired.
As pods are ephemeral with replicasets enforcing this by scaling the number of pods up and down, this presents a problem that pods become impossible to reference.
Services fixes this problem by providing an abstraction over pods and provide an addressable method of communicating with pods.
Services operate on “layer 4” (TCP/UDP over IP) in the OSI model.
Deployments manages replicasets and can be used to run rolling upgrades between versions of your applications.
This is the most common resource type that is used, and templates replicasets and pods through a single interface.
In the case of updating a Deployments template, to say, deploy a new version of an application, the deployment will create a new replicaset and manage the rolling upgrade from the old, to the new.
However to note, deployments do not currently handle rollback automatically.
Well designed applications should try to follow the 12 factor app manifesto, for configuration of your applications, this should store configuration in the "environment". Although common security practices now state that storing config in the environment can cause accidental leakage of secrets as some applications spew their environment on failure, nevertheless configuration should be stored seperately from the built application as configuration changes per environment. (development, staging, production).
ConfigMaps solve the problem by allowing to mount configuration files into a Pod as an Environment variable or as a file system mount.
Secrets are very similar to ConfigMaps, however they are, by their name, "secret" [3][4].
A Daemonset
ensures that all Nodes run a specific Pod. This is useful for running something
such as a logging agent like fluentd on all Nodes.
It is also possible to ignore certain Nodes by using Taints
In most circumstances, services and pods have IP addresses which is only accessible from within the Kubernetes cluster. With the services being isolated from internet traffic.
"An Ingress is a collection of rules that allow inbound connections to reach the cluster services."
It can be used for load balancing, to terminate TLS, provide sexternal routable URLs and much more. An ingress is just another Kubernetes resource, however in most cases it is required to have an Ingress Controller Such as Nginx or Træfik.
[1] https://medium.com/google-cloud/kubernetes-configmaps-and-secrets-68d061f7ab5b
[2] https://medium.com/google-cloud/kubernetes-configmaps-and-secrets-part-2-3dc37111f0dc
[3] https://kubernetes.io/docs/concepts/configuration/secret/
[4] https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/