Even though Docker and Kubernetes shares some similarities in their deployment structures, terms etc. It is important to note that they are not the same. Docker is the precursor to Kubernetes and even though it has some semblance of orchestration it isn’t nearly as powerful as Kubernetes. There are also deviations in the command structure and the configurations that have to be considered when working on each. In SIEMonster terms the areas where you will use either is very specific. Kubernetes will always make up the central “controller” environment and the log aggregator (hydra) will for the foreseeable future use Docker.
For the practical application of configurations and troubleshooting the hydra the following is important to note and understand.
Containers are similar to pods in that is houses the programmitical functions required for the system to perform the required actions. It allows for abstraction from the base or baremetal OS making the services more stable and reliable and also easier to recover in case of failure. Unlike Pods in Kubernetes, Docker containers are always singular in nature. In Kubernetes one can group a number of containers into a Pod, similar to the way a group of killer whales are refer to as a Pod.
On the Hydra, all containers have been configured to be run as services. This allows for the granular and static configuration of the containers to provide a robust and reliable environment. As the containers have been configured as services it allows for services to be restarted should it be needed rather than trying to manually start containers with many parameters that need to be added.
Just like Kubernetes there are mapped volumes for the Docker containers. The biggest difference being that in Kubernetes you require both a persistent volume as well as a persistent volume claim. In Docker you purely redirect a folder inside the container to a path on the local disk that is not volatile. This is where any data and configuration items are stored.